Tools and other software EPG-Buddy a new EPG Tool with easy usage. (2 Viewers)

[mbb]

thanks for your answer
I will be more than happy to test your product.

I tried your advice to use the usual way for "External XML" but it doesnt work
In the grabber log it say "file type unkwnon"

.xz type is not usual on Windows

because this compression protocol is a little bit unusual only 7zip can handle it

Adding Rytec as a full data source would be a must for many non german EPG-Buddy users since Webgrab+plus is very slow and not reliable for a lot of countries.

 

[Lehmden]

Hi.

I will be more than happy to test your product.

Thanks.

but it doesnt work
In the grabber log it say "file type unkwnon"

Yep, expected that. But hope dies last...

We've started to talk about this internally already but my programming mate @lightshock who's writing the grabber module (I'm doing the GUI and the settings stuff) is working for a company that's develop and take care of software solutions also used in medical and rescue services... He has a lot to do those days, as you can expect.

Adding Rytec as a full data source would be a must for many non german EPG-Buddy users since Webgrab+plus is very slow and not reliable for a lot of countries.

I'm completely with you. We are looking for a reliable and fast data source for whole Europe a long time already. Some options we have tried and discarded in meantime. Rytec was known already but as it is not very well structured (too much different files with strange names and lot's of duplicate stuff) it hadn't got high priority for testing up to now. As we are both Germans, for "us" (TVSpielfilm) and for Northern America (tvguide.com) we found reliable and fast sources right from the beginning. And the rest of the world can use WebGrab, also it's not fast and very complicated... So we had a "global" package but we always wanted to support more countries with fast data sources. This looks like a way to achieve this in not too far future.

I'm pretty sure we can support this in one or the other way but this will most likely take it's time. If you can be patient you will get what you need when time comes...

 

[mbb]

no worries
I have already a working solution, I can wait for a better one

In the meantime, let me know if I can help

 

[crusadre]

I downloaded EPG-Buddy_0.5.0.8.zip and Bitdefender is saying it is infected.
"Trojan.GenericKD.42587288" Can the source be checked and if infected cleaned? Or is this a false alarm?

 

[Lehmden]

Please look a few post above...

 

[TBacker]

A quick bug report...

Using EPG Buddy to get TV guide data into MP1. There is a local station that has it's programming duplicated on an LP and an HD.2 channel. Both are shown as separate listings (different ID's) in the TV Guide data, so I chose one (set the mapping using database mode) and disabled the other (unchecked "grab from TVGuide?"). That listing didn't work right, so I tried to switch to the other. When I did, it wouldn't allow me to enable it (I could check it, but it didn't stick), nor would the mapping take.

I went into EPG Buddy's sqlite config database and couldn't see an issue other than it was the only entry with mixed case "True" in the column "RUN_E2T" (all other values were upper case TRUE and FALSE).

I made the config changes direct to the database, reopened EPG Buddy, and all was well again.

 

[Lehmden]

Hi.
Thanks for reporting.

"True", "TRUE" or "FALSE" are Boolean values and normally they shouldn't be case sensitive. Even "0" and "1" should work afaik. Aside this the "RUN_E2T" column only stores if the user wants to compare this channel with TVDB after data grabbing or not (TRUE or FALSE). It has no influence of anything else.

I think your issue was solved by the restart of EPG-Buddy, not by editing the database (also you haven't done any harm to it) Nevertheless I will have a closer look, if there are issues with the case of "True" and "false" inside the source code...

 

[TBacker]

"True", "TRUE" or "FALSE" are Boolean values and normally they shouldn't be case sensitive.

I've done some programming, so I understand these things. I have no idea if it was related, it was just interesting that it was on the item that could not be changed within the program. Being it's a text field within SQLite, I thought maybe there s sub or function that was doing a direct compare to upper case, i.e. if = "TRUE" while another was writing it mixed case.

I think your issue was solved by the restart of EPG-Buddy, not by editing the database (also you haven't done any harm to it) Nevertheless I will have a closer look, if there are issues with the case of "True" and "false" inside the source code...

Trust me, I had restarted multiple times before I decided to go through the trouble of rooting around in the config directly.

One last issue, and I'm not sure on which end this is a problem, EPG-Buddy or the xmltv plugin, but the guide is off by 4 hours in MediaPortal (MP1). I see the XML data shows my time zone as -0400 in the listings, and my time zone is eastern, so it is -4 hours (-5 with DST). In MediaPortal, the listings for 6PM show up at 2PM.

All computer clocks are correct and on the correct time zone (have been for years).

Thanks for all your help and work on this project! With the death of Argus, I'm back in the world of TVServer and having to work out the kinks, and EPG-Buddy fills a hole in that picture well.

 

[TLD]

You can correct the time offset in TV server config - plugins - xmltv plugin

You will need to use the force import button in xmltv plugin to see the time changes in the EPG.

 

[TBacker]

Thanks TLD. I ended up going that route.

The docs for the xmltv plugin say that they assume that the listings in the xml file are local time, which seems counter intuitive when the xml file is also providing an offset from GMT. Hoping I'm not going to have to manually change that every tine DST switches, but I think that'll be the case.