mythfilldatabase only updates until midnight one day at a time with SVN 12697

[anonymous]

I just upgraded to svn 12697 and noticed that mythfilldatabase does not work right with tv_grab_se_swedb. With earlier svn versions i ran mythfilldatabase with --max-days 14 and that worked without problems. But now no matter what options i give it only seems to update until midnight the same day. It might have something to do with changeset 12499?.

[stuartm]

What version of xmltv are you using? Have you tried the latest version?

tv_grab_se_swedb was actually one of the grabbers specifically tested before [12499] was applied.

[anonymous]

XMLTV module version 0.5.45 This is tv_grab_se_swedb version 1.2, 2006/05/24 13:10:59

I had an earlier version before but then it complained, so i uppdated. I have re-done all my channels using xmltv and updated with mythfilldatabase --manual. But there is no difference.

I have been running svn since release of 0.20 with almoast weekly updates and this has always worked until about 2 weeks ago i did not notice it because i had 14 days of guide data, but that ran out yesterday becouse of old version of XMLTV, After update i only got 1 day at a time.

Great work on this project it's really solid now

[stuartm]

Ok I'll need logs using "-v xmltv" and all parameters you are passing to mythfilldatabase.

[anonymous]

mythfilldatabase --max-days 14 -v xmltv

[stuartm]

Does running the following produce output?

tv_grab_se_swedb --config=/home/{username}/.mythtv/{configfile} --days 1 --offset 1

If no, what about "--offset 2"?

From the logs it seems the grabber isn't finding any programmes for the second day, so mythfilldatabase stops looking. The swedb grabber appears to work for me outside mythfilldatabase, returning programmes when run with the above options, so I'm not sure why it's not working for you when run through mythfilldatabase.

I may force mythfilldatabase to always look at least 3/4 days before giving up, but I don't think that will solve your problem.

[anonymous]

tv_grab_se_swedb --config-file=/root/.mythtv/Analog.xmltv --days 1 --offset 1 returns data, and it responds to days 1-14 and offset 1-2 i had to change --config=/ to --config-file. So the grabber seems ok but not when run through mythfilldatabase.

Could it have something to do with my setup? i have a pvr500 and both tuners use the same source Analog.xmltv

[stuartm]

One of the other devs who uses tv_grab_se_swedb confirms it is working for them, so we're probably looking at configuration/usage problem.

Although I don't think it's related, if both tuners use the same set of channels they should both use the same video source. The log suggests that you're using one source for each tuner.

I've just added a debugging string to mythfilldatabase which might help. Could you update and run "mythfilldatabase -v xmltv" without "--max-days 14".

[anonymous]

Hi

I have found the problem. might call it miss config or a bug it depends.

here what has happened. I have 2 Analog tuners both using the same channel config analog.xmltv. I also have 2 DVB-T cards running boxer.xmltv. before i was using xmltv on boxer as well but went over to just using EIT so i just commented out the channels in boxer.xmltv and removed the xmltv address on the digital channels.

This has been working in earlier svn versions until this update. I tried to enable MTV as a test in boxer.xmlv and configured that channel to use xmltv insted of EIT and then it all goes fine and updates both sources with 14 days of data.

So the problem seems to appear when you have a source configured for xmltv but don't have any channels configured.

might need some error checking on this type config error?

[stuartm]

(In [12964]) Fixes #3034

Check that at least one channel per source has an xmltvid before using the grabber for that source.

Reset endofdata to false for each new grabber.

Rearranged the eitonly/null grabber checks and VERBOSE strings into a more logical order.

[stuartm]

(In [12965]) Refs #3034

Removes continue added in [12964], we don't want to skip grabbing if we are using it to populate the channel table. Reseting endofdata should be enough to avoid the bug in #3094.