LiveTV hangs when a recording is finished and a new on starts (no channel change)

[tino.keitel+mythtv@…]

While just watching LiveTV, I often get a hang when one programme is finished and the next one starts. I don't switch to an new channel, I just let LiveTV running as is.

Frontend and backend logs are attached.

[tino.keitel+mythtv@…]

Frontend log

[tino.keitel+mythtv@…]

backend log

[tino.keitel+mythtv@…]

frontend log, really

[tino.keitel+mythtv@…]

I forgot to mention: I get this with SVN 11024, and it also happened with older SVN revisions

[wmunson@…]

Replying to tino.keitel+mythtv@tikei.de:

While just watching LiveTV, I often get a hang when one programme is finished and the next one starts. I don't switch to an new channel, I just let LiveTV running as is.

Frontend and backend logs are attached.

I am also seeing this behavior. I have seen it since 0.19. What I have noticed is that the sequence is Watch live tv, watch a show while its recording (no channel change), then when it should go back to live tv instead I get dumped to a blank screen which does not return to the menu. Pressing ESC does return to the menu.

[pansyg@…]

it's the same issue i reported already (#2045, 2 problem). it exists since about 3 months in svn.

[tino.keitel+mythtv@…]

I assume that the last comment went into the wrong ticket, since the tickets it refers to talk about DVB-S and the DiSEQ branch, and mentions channel changes. However, I use DVB-T only, and I don't change a channel when the bug occurs.

[wmunson@…]

I do not think its related to a specific card type. I have the problem with a PVR-250 (2 different models)

[pansyg@…]

no, it didn't went wrong. i don't change any channel, only the program schedule change. i have 2 cards and it only occurs on one of them.

[anonymous]

Same behaivor here with twinhan dvb-t card on change schedule I get a no video error screen on frontend. I press ok go back and enter LIve TV again and it works fine again. THis happen randomly.

[anonymous]

I get not error screen here, the screen just stays black forever (using SVN).

I have a channel with a program change every 30 minutes and I get the black screen at least every second program change. This is very annoying, but I also would like to assist in debugging and fixing this issue.

Btw., I use a DVB-T USB box (Terratec CinergyT2).

[Joe Votour <joevph@…>]

I see the same problem, and it is especially noticeable with HD (since the baseball playoffs are on, and they allocate three hours per game, but they run longer).

I didn't run either the frontend or backend with verbose enabled, but I will do so for the upcoming games to get more information on what the problem is. I don't get a black screen, I instead get a still frame of what was last on the screen, and I have to restart LiveTV to get things going again.

That said, I do have some snippets of the frontend and backend logs (The program guide listing changed from "MLB Baseball" to "Cheers" at 7:30PM), which I am attaching (jvlogs.txt).

Note that I am not using NFS between the frontend and the backend, I'm using the MythTV streaming protocol. I find that it seems to perform better than NFS, even with the various parameters specified in the Wiki.

-- Joe

[Joe Votour <joevph@…>]

Logs from the frontend and backend when schedule change occurs

[Miwer]

Hi,

I also see this problem, and it's been going on for a while now. So I made some log files, and attached them here (the ones marked Miwers). These log files were made with the latest SVN at the time (11673). I've used the following verbose settings:

backend: important,general,record,file
frontend: important,general,playback,file

To aid in the reading of the log files, I also made a timeline, which goes like this:

15:52:15 -> I start LiveTV
15:55:00 -> show ends, next show begins
15:57:08 -> changing channel
16:00:00 -> show ends, next show begins
16:05:00 -> show ends, frontend halts with frozen picture, log spamming :(
16:05:32 -> I exit LiveTV
16:05:38 -> I start LiveTV again
16:15:00 -> show ends, next show begins
16:18:51 -> I exit LiveTV

I hope this helps someone to find the flaw.

[Miwer]

backend.log - refer to ​comment 10

[Miwer]

frontend.log - refer to ​comment 10

[tino.keitel+mythtv@…]

I still have the problem with 12167. Janne Grunau provided a patch that creates a new show very 2 minutes so that I can reproduce the problem nearly every 2 minutes with a station without EPG.

A workaround is to pause LiveTV for a few seconds.

[tino.keitel+mythtv@…]

create a new show every 2 minutes to reproduce the problem quickly

[myth@…]

I've seen this problem since 0.19, but its sporadic, not every program change, especially annoying on the kids shows in the morning with lots of 5 minute shows and lots of 'dad its frozen!'

As a datapoint I recently changed the decoder from libmpeg2 to 'standard' (ffmpeg) and the frequency of the problem has plummeted. I've got an Athlon64.

Sometimes I get the show 'feezing', othertimes I get "Mythtv has encountered a problem displaying video".

[tino.keitel+mythtv@…]

I just switched from libmpeg2 to standard but still get very many LiveTV hangs. Sadly, it looks like a fix for this isn't planned for 0.21, as the milestone was removed.

[geoffp@…]

I was also plagued by this problem. I can't be sure I wasn't twiddling other options as well, but it seems that changing to "Standard" decoding *and* turning OpenGL vertical sync OFF has made this issue completely disappear for me. Perhaps that's where part of the problem lies...?

That's with a GeForce? 5200 and the "stable" 9-series Nvidia drivers.

[dave@…]

I experience this problem as well. log spams "LiveTV Forcing JumpTo? 1".. ESC and back to live tv fixes it but happens every day at random times, but always either at the top or the bottom of the hour.

[anonymous]

Replying to geoffp@gmail.com:

I was also plagued by this problem. I can't be sure I wasn't twiddling other options as well, but it seems that changing to "Standard" decoding *and* turning OpenGL vertical sync OFF has made this issue completely disappear for me. Perhaps that's where part of the problem lies...?

That's with a GeForce? 5200 and the "stable" 9-series Nvidia drivers.

More information: I've re-enabled OpenGL vertical sync, and it's been rock-solid for a week now. I'm still using Standard decoding. It has also occurred to me that at the same time I made the two above changes, I enabled every kind of vertical sync I could in the nvidia-settings panel.

[david@…]

One difference in the logs provided by Miwer is that in the recording transitions that doesn't hang, FileChangedCallback? is called, while it isn't in the transitions that hang. Looking at some extra debugging output, FileChangedCallback? is called from FileChanged? in decoderbase.cpp which is in turn called from GetFrame? in avformatdecoder.cpp.

I haven't figured out why/when FileChangedCallback? is not called, but I suspect that if we managed to find out, the bug could be fixed.

[david@…]

Here's some more information from a log of a failed program transition as compared to a successful program transition.

The successful program transition was at 04:00:00, the failed one was at 05:00:00. Interesting to note is that the failed one tried to do two SwitchLiveTVRingBuffer calls in a row within three seconds (05:00:00 and 05:00:03), seemingly the second SwitchLiveTVRingBuffer run is executed before the first SwitchLiveTVRingBuffer run is allowed to finish.

Looking at the frontend logs, the frontend then tries to open the file associated with the first SwitchLiveTVRingBuffer a couple of seconds later (05:00:07) which fails as the backend has already moved on to the second file (which has a filename reflecting the later 05:00:03 time).

I'm trying to get some backtraces and extra debugging information to decide why the SwitchLiveTVRingBuffer function is sometimes invoked twice and why it is sometimes invoked twice (leading to the frontend failure).

I've created a html file which compares the frontend and backend logs for the successful and unsuccessful runs side-by-side which I'll attach.

[david@…]

Comparison of frontend and backend log for successful and unsuccessful program transitions

[danielk]

Duplicate of #1153.

[tino.keitel+mythtv@…]

I guess that this ticket should be reopened.

Quoting from #1153:

01/13/07 01:41:13 changed by david@…

From what I can tell from the logs, it seems to be a different issue from the one remedied by the above patches as the SwitchLiveTVRingBuffer call isn't called twice and the RingBuffer?? seems to switch correctly at 08:22, but it's not being filled.

[danielk]

(In [12550]) Fixes #2335. Fixes a ringbuffer switching race condition.

[danielk]

Sorry, [12550] fixes #1153 not this bug.

[danielk]

(In [12570]) Refs #2335. Demotes "Enabling Full LiveTV UI." message from -v important, to -v record.

[CHRONiK]

Has anyone tried the 12570 fix? If so, does it work? This problem has basically stopped my from using my mythbox.

[tino.keitel+mythtv@…]

As Daniel states, it was not a fix, but just a change that affects the debug output.

Unfortunately, the station that triggered the bug for me is now gone, I'll look how easy I can reproduce this bug with another station.

[CHRONiK]

The problem occurs with me on every station, every program change without fail and on both tuners (dvico dual card). Lots of "ignore eof decoder.." messages with -v playback and prebugger messages when running mythfrontend from cmd line. If I can be of any assistance let me know. My specs are:

P4 3.0ghz 800fsb 1gig dual channel DDR400 RAM Intel 875chipset Dvico Dual Tuner (first revision, with usb) Nvidia 6600 using 9631 drivers. Fedora Core 5 using 2.6.18.fc5-2257 kernel. All packages updated as of 1/2/07 Myth packages 0.20-151 atrpms. 30/1/07.

[david@…]

Replying to CHRONiK:

The problem occurs with me on every station, every program change without fail and on both tuners (dvico dual card). Lots of "ignore eof decoder.." messages with -v playback and prebugger messages when running mythfrontend from cmd line. If I can be of any assistance let me know. My specs are:

...

Myth packages 0.20-151 atrpms. 30/1/07.

If you are using 0.20 based packages, chances are that you might be encountering the bug documented in #1153 (which has been fixed in the mainline branch but not in 0.20-fixes).

[anonymous]

Replying to david@hardeman.nu:

If you are using 0.20 based packages, chances are that you might be encountering the bug documented in #1153 (which has been fixed in the mainline branch but not in 0.20-fixes).

Apologies but this is probably not the correct forum for this. I am a bit of a noob, but how can I install these patches with FC5? I thought updating to the latest myth0.20-15x packages would apply any fixes.

BTW. I configured XvMC and test to see if this problem occurs while using XvMC, it doesnt, but instead I get "Error Occurred while display video" after a much longer period of time (ie. couple of hrs of play). The below errors are displayed in the log.

2007-02-02 09:00:06.512 NVP: Prebuffer wait timed out 10 times. 2007-02-02 09:00:07.540 RingBuf?(/myth/recordings/1503_20070202090000.mpg): Invalid file (fd -1) when opening '/myth/recordings/1503_20070202090000.mpg'. 2007-02-02 09:00:07.540 NVP, Error: SwitchToProgram?'s OpenFile? failed. 2007-02-02 09:00:07.540 NVP, Error: Unknown error, exiting decoder

[david@…]

Replying to anonymous:

Apologies but this is probably not the correct forum for this. I am a bit of a noob, but how can I install these patches with FC5?

You basically have three options.

A) Recompile MythTV yourself with the patch applied B) Persuade a developer to backport the patch for #1153 to 0.20-fixes which would then be included in later packages C) Wait for the next release

Replying to anonymous:

I thought updating to the latest myth0.20-15x packages would apply any fixes.

I do not use those packages myself so I can't know for sure, but the package names suggest that they have been created from the 0.20-fixes branch. And the fix for #1153 has not been committed to that branch.

Replying to anonymous:

BTW. I configured XvMC and test to see if this problem occurs while using XvMC, it doesnt, but instead I get "Error Occurred while display video" after a much longer period of time (ie. couple of hrs of play). The below errors are displayed in the log.

Yes that could still be bug #1153

[anonymous]

Clearly this is not happening for everyone (but it is for me), does anyone have any ideas what the similarity is between those who experience it and those who do not

Is it affected by any/all of the following for example

1) Motherboard (chipset) 2) Tuner Card type 3) Hard Disk type 4) Hard disk manufacturer 5) Hard disk acoustic management setting or DMA

as a for instance Im seeing the issue with mythtv versions 0.19 and 0.20 with the following hardware MSI Socket 478 (intel i810 chipset) motherboard with Pentium 4 1.7Ghz With the 0.19 build (knoppmyth r5c7) the problem seems to almost disappear with acoustic management set to "fast" however in 0.20 (Knoppmyth r5e50) its apparent regardless of the acoustic management setting.

[anonymous]

I have been chasing this "bug/feature" for about the past 3 months now with Fedora 6 and MythTV .20. I tried all the tricks that I knew about tweaking linux, i.e. hdparm, setpci, turn off all services(yea thats right, I turned off everything except mysqld and lircd), and a couple of other things. I even tried different hardware. All to no avail. I finally camne across this post ​http://www.gossamer-threads.com/lists/mythtv/users/258531 where they discuss tuning mysql. I started with the settings below for my /etc/my.cnf file.

old_passwords=1 key_buffer = 16M max_allowed_packet = 8M table_cache = 128 sort_buffer_size = 16M net_buffer_length = 8M thread_cache_size = 4 query_cache_type = 1 query_cache_size = 4M

This did improve the freezing slightly. It still froze during the night when it ran mythfilldatabase. So I did a little research on tuning mysql myself(there is alot of stuff to look at so I didn't really learn that much). However I eneded up with a /etc/my.cnf that looks like this in th mysqld section.

old_passwords=1 key_buffer = 32M max_allowed_packet = 16M table_cache = 1000 sort_buffer_size = 32M net_buffer_length = 16M thread_cache_size = 200 query_cache_type = 1 query_cache_size = 24M

And since I started using these settings I have not had a single freeze up at any time, or any other issue for that matter. As soon as I went a day without a freeze I did a complete reinstall of Fedora core 6 and Mythtv .20 and used the new settings for mysql server. IT WORKS FLAWLESSLY :) :) :). By the way, I am now using a E-Machines P4 2.6 Ghz with 768 MB of ram and 2 PVR-150. When I first started, I was using one PVR-150 and one WinTV-GO. I eventully gave up on the WinTV-GO card thinking that it was causing some of the problem, but now that I have gone about a week and a half without any issues(no reboots), I'm starting to think about trying the WinTV-GO card again. The bottom line is that it was deffintly the mysql server performance that was causing this problem for me and I bet for alot of other people as well. I hope the developers see this and can help get it right in upcomming releases. If you run mythbackend with the "-v all" option you will see that myth is doing ALOT and I do mean ALOT of sql queeries for seek positions.

[anonymous]

I tried the mysql tweaks above, it does not seem to have stopped the problem completely but seems to have lessened it a fair bit .. no doubt some more testing will determine how big a difference this makes....

[anonymous]

You may want to try running mythbackend with the --noautoexpire and --nohousekeeping options. This is one of the the things I tried durring my 3 months of chasing this "bug/feature". Running mythbackend this way helped with the freezing as well, however it also lets all the LiveTV recordings build up without deleting any. I was thinking of using a script to run mythbackend with those options until 4:00 AM then run mythbackend with no options for an hour or so, then run mythbackend with said options again. But I just couldn't bring myself to do that much "rigging".

Another thing that seemed to help with the freezing was setting the playback speed to .95(through mythtv interface) or even .99(through mysqladmin). However this will cause long LiveTV seesions to get out of time with real world clock :(. I thought that buy setting it to .99, I wouldn't be able to see a big time discrepency(or at least I wouldn't mind it) but alas, I was wrong. So I kept debugging until I found the above mysql settings.

I also tried the xvmc as the plackback decoder(using a FX5200), that did help a little with the freezing, but it didn't stop it. And I really didn't care for the quality. So I'm still using Standard(ffmpeg).

I think that is all I tried(hard to remember 3 months of debugging). Make sure that your hard drive is set to I/O support = 3 (32-bit w/sync)(if your using an IDE drive) with hdparm. If it's not you will want to set it and probably manually set some other hard drive settings(depending on your hard drive).

[anonymous]

This is from the same guy as above:). I just thought of something else. I think I remember a "seek time" setting somewhere in mythtvsetup or frontend setup. I think its set to 100 by default(I'm assuming thats 100 frames). That was the very last thing i was pursuing when I came across the mysql settings above. Since I saw ALOT of sql queeries for seek positions when running mythbackend -v all, I was going to jack that number up to 1000 or so to see if that would help with the freezing. Never did do that though(was researching the ramifications of doing so when came across said mysql settings). I have a feeling that it might help but FF, RW and skipping will probably suffer in someway.

[anonymous]

Hmm you said This is from the same guy as above:). I just thought of something else. I think I remember a "seek time" setting somewhere in mythtvsetup or frontend setup. I think its set to 100 by default(I'm assuming thats 100 frames).

but I dont see this either in mytv-setup (in card or recoridng options) or in setup->tv->playback settings

Does it depend on the type of card im using a Hauppauge Wintv Nova T DVB card

[anonymous]

Actually the name of the option is "Fast forward/rewind reposition amount:". It is in the mythfrontend setup in "Utilities/Setup?->Setup->TV Settings->Playback" on the "Seeking" page. Like I said above, I never really went down this road though, so I don't know what the ramifications/benifits if any it will bring. I'm using 2 WinTV PVR-150 cards(most of the above mentioned debugging is with 1 PVR-150). I did actually purchase a pcHDTV 5500 card to try a digital tuner at one point. To be honnest wtih you I was very disapointed with it. I had a little bit of a hard time getting it to work and once I did the quality was bad compared to my PVR-150. And on top of that, it turns out my cable company doesn't allow me to get but 1 digital channel without a set top box. I understand my pcHDTV 5500 card is not the same as your WinTV Nova card, I'm just conveying my experience with the 1 DVB card I had tried. You may also want to try looking at the "HD Ringbuffer size (KB):" setting in the Utilities/Setup?->Setup->General->TV Settings->General section on the "General(Advanced)" screen. I think that will affect your playback since you are using a DVB card, but I may be wrong(heck it might still be affecting me, I don't know). I don't think I ever did find out if the "HD" meant High Def or Hard Drive. I have mine set to 9400, which I'm sure is the default, since I stopped messing with this setting when I took the pcHDTV card out.

Well there are some more of the things I did durring my 3 months of chasing this thing. I must say though, it really does seem to be that it was the mysql settings I mentioned above that fixed my situation. I still have NOT had any total freezes since I started posting here. I still get about a 2 or 3 second "pause" at the time mythfilldatabase runs(near the end of it) but then it starts playing just fine. Normally I'm not watching TV when mythfilldatabase runs though so thats no big deal for me. At one point last week, I left my mythtv run in live TV mode for over 48 hours with no problems.

[anonymous]

despite tried a wide range of tweaks and mysql performance config changes im still getting this issue... I'm not alone as this rather lengthy thread (​http://www.mysettopbox.tv/phpBB2/viewtopic.php?t=14642)shows this problem is manifesting itself in a wide range of hardware and mythtv versions.

[anonymous]

This problem is showing it's ugly face even on multiplex's I don't have guide data for, sure enough on program transitions I get the video error message.

The Mysql changes made no difference for me, I use xmltv data sources but as I said even channels I have no data source for the error still occurs like clockwork on both Ubuntu & openSUSE box's, it's driving me insane through the constant complaints of wife and 6 year old son, I think the severity rating needs to be lifted to save my sanity.

Unfortunately I'm no developer, heck I don't even work in IT, just a self taught computer geek so my ability to debug these issues is limited....Cheers

Mark

[anonymous]

Well, its been about a month now since my last freeze. Again ever since I adjusted my mysql settings I have not had a freeze. Like I said above, I still would get pauses in between shows but it never froze. Then 2 days ago I commited the ultimate sin, I messed with some more settings to see if I could tweak mythtv even a little more. I think I got away with it because its even better now.

I started running mythbackend with the --noupnp option and now I'm not even getting the pauses in between shows. I beleive upnp server is more for a game console setup which is not in my enviroment. With the upnp server enabled, my mythtv box would show up in my Vista's network places as a media device but I never could do anything worth whiue with it(clicking on the link just opened media player). Bottom line is try running "mythbackend --noupnp" and see if that helps. Unless of course you are specifically using the upnp server at which point, I don't know what to tell you.

[anonymous]

Well Ive tried it running with noupnp running for 24 hours or there abouts during that time i had 3 issues with program boundaries, 2 freezes and one "Error Was encountered while displaying video" ... Ive come to the conclusion that if you leave livetv running and running and it manages to get past the first few program boundaries its lags far enought behind "live" (say 6+seconds) that the error is less likely to occur.

I think its more likely to occur on the first or second boundary.

[anonymous]

Following reading a tip on the Knoppmyth forums I have unchecked "wait for SEQ headers" in capture card settings>recording options in mythtv-setup.

The machine has been running live TV for the past 12 hours and I have not, touch wood had the video was encounted error. Never have I been error free in live TV mode for more than 3-4 program boundaries before. I don't even know what SEQ headers are but disabling it seems to have help enormously.

I'm running DVB cards on Suse 10.2, I also applied the above mentioned my.cnf changes.

[anonymous]

Ive tried it too (unchecking the wait for SEQ headers). Ive been soak testing it for about 4 days now. During that period ive had 2 freezes of playback on a boundary (frontend playback freezes, backend continues to record). Ive also had about 4-5 "Error Was encountered while displaying video" errors. Its my guess that it helps a little, but its still not a fix for me ... -- dkh

[postmaster@…]

i have the same issue r12376, r12172 and r13181 ...i did some tests: issue is not related to dvb, happens also with ivtv, and iptv (vlc stream). On my system (separate backend and frontend) freezes randomly 1 out of 6 program transitions. if i pause playback for few seconds to be behind livetv..it doesnt freeze that often..at least for 16 consecutive hours and then froze again(thats the test i did) i tried 3 different backend-frontend HW configurations including gigabit ethernet+network but the freezing keeps happening. i tried r10505 and doesnt happen..but of course...i know thats usseless because its too old stuff. hope it helps..sorry for my english..:(

[anonymous]

Replying to postmaster@profesionalweb.com:

i have the same issue r12376, r12172 and r13181 ...

...

i tried r10505 and doesnt happen..

If you've already tried four revisions and know that the problem was introduced between r10505 and r12172, then perhaps you could narrow it down further by doing a bisect search for the changeset that introduced the problem?

In case a bisect search is new to you, the idea is basically:

FAILS = 12172
WORKS = 10505
Loop

TEST = (FAILS + WORKS) / 2
Compile and run revision TEST
If it works, then WORKS = TEST, else FAILS = TEST

End

With just four tests you'll have narrowed the window from 1600 changesets to about a hundred, with eight tests you'll be in the single digits, and with 10 - 11 tests you should be able to find the exact changeset.

[tino.keitel+mythtv@…]

Please also look into the other comments: "I have seen it since 0.19."

So I doubt that the bug wasn't present in revision 10505. I my case, I also remember to have seen this with SVN trunk before 0.20 was released.

[stuartm]

Narrowing down the revision isn't going to help fix this problem. It's related to the newer method of handling livetv and so we know when the bug was introduced, we just don't know the cause yet. I suspect there may be more than one problem - descriptions of this bug seem to vary.

I'm actually able to reproduce the "LiveTV JumpTo? 1" loop on one of my machines and when I have the time I'll work on finding the cause.

What currently happens and which should definitely never occur, is that we seem to get stuck in this loop waiting for the new file to appear, we never give up and therefore I've seen logs of 2GB filled with "LiveTV JumpTo? 1" after which the machine runs out of diskspace.

[anonymous]

I discovered the (unchecking the wait for SEQ headers) a few of weeks ago. And since then i dont get "error displaying video" problem i also applied the mysql patches at the same time.

attached my posting from the knoppmythforum

One thing I did notice is one of the options have been droped in the dvb-t driver the use hardware mpeg decoder check box. This makes the recodings about 10 - 15% larger and also means any post processing job such as myth lossless transcode and mytharchive have to work out the primary sound channel.

I am sure its something to do with the new live tv method now the system has to close the file stream reopen a new file stream reconnect to the new stream and start to pay. Turning or wait for seq header probably reduces that delay on my machine enough to stop it breaking. Now on a program break i just get a second / second/half freeze then it continues this i think is probably the player waiting for the seq headre in the new recording file.

I know it would be a major rewtite but surely ir would be better if live tv (and all sequential recording in fact) were recorded in one long file then split by a background job later. Or if not split just entered into the database as the same mpeg file with edit points set up for the start and finish times for that program.

so if i start watching live tv (same channel) at 7:55 till 9:05 one file is recorded ch1_0755_0905.mpg (simplified example of myth filename) and four entries to the database all saying that is the recording is the recorning file the first would have its start time as 0min and end time as 5min the second would have its start time as 5min end time as 35min the third would have its start time as 35min and end time as 65min and the last would have its start time as 65min and end time as 70min (four programs two half hour programs in between)

then a background job could split them into four ind files or maybe it you decided to transcode say the second program a new record could be created ch1_0800_0830.mpg and the second jobs dependency on the first file removed. when the other recordings are expired there dependency on this shared file is also removed. when all dependencies are removed to the origonal file the file is then removed.

Its probably not a good explanation but i think you can get an idea. This as i explained in my knoppmyth post could be expanded to a whole mux making scheduleing back to back recording with a start early and a finish late time much easier. At the moment if i record two programs back to back and specify a couple of minuites start early and finish late time It has to use two dif tunners in the above approach one file could be recorded from one tuner then split at the end. ( a start bookmark could be created in the second recording marking the start of the second program.

Ok this is not a quick fix for the above problem but it is a fix and it would make myth much better (especialy if you could record more than one channel from the same mux)

Regards

simonf

Joined: 09 Nov 2005 Posts: 89 Location: Manchester UK PostPosted?: Wed May 16, 2007 10:13 am Post subject: DVB Recording options my opinions and my 90% fix Reply with quote Edit/Delete? this post Hi All,

I to was plaged with the this video can not be displayed problem, I applied the changes to the mysql database which improved things.

I had started to get the problem again with my dvds not recording the correct sound track again (from dvb sorce). My origonal fix was a patch to mythburn which identified the largest sound file and deleted the other one before a remplex. Later i discovered that if you went into the input cards > recording options for a given card there was an option called "Use Hardware MPEG Decoder"?? which i think was badly named. What this did was to only record the first audio track in the recording. Any how back to the story when the problem started to reoccure i decided to check out the input cards > recording options again and low and behold this option has gone. Sad So back too the problem in this thred I only had a problem with "video can not be displayed " since the dvb recording options changed ( I figure and i could be wrong; that there was some other changes in this section to also make the dvb interactive work) . Anyhow i noticed the first option in the dvb recording settings setings setting was wait for SEQ Header, this was checked i unchecked it on both my cards and have only had a problem once in the past week. I may be looking at this too simplisticaly but i figure that if a TV program ends and myth then restarts a recording if it has to wait for a SEQ header before it starts recording aain there is bound to be a delay ?? if this delay is too long you then get the error.

To be honest i cant see why myth cant record by channel & time of even better complete MUX & Time. That way after the recording ends a job could be run to convert / each program into a seperate file. Playing back live tv would just meen the frontend would need to playback the appropriet stream from within the file. This would give all sorts of advantages.

Firstly; you would not nave the above problem with live tv.

Secondly; you would be able to record Two / Three ... channels/programs at the same time using one card as long as they were on the same Mux.

Thirdly; I and I think others use the start recording early / late opions. if you have back to back recording on the same channel / MUX. Currently i find these recordings have to be done on alternate tuners to get the 2min early and the 2min late not to clash. If they were recorded as one file and split later not only could the recording be done using one tuner but both recording could overlap (ie the file could be extracted with an overlap of 2 min early/late).

Anyhow thats my thoughts

so the fix for me

Go into the mythtv setup (Alt-s From X frontend)

Select input cards

Select your input card

Select recording options

Uncheck "Wait for SEQ Header"

It has helped a lot for me (not fixed completely) hope it works for you all.

SimonF

ps

i am running

Running:- Intel 930 3G dual Core jetway motherboard 945 Chipset integrated Intel Video (disabled) Seagate 500G Sata HDD 6200 128m Video Card 2 * jetway DVB-t cx88 pci cards and a peak (u-wide) usb2 dvb tunner Samsung Sata DVDRW 1536M Ram

[tino.keitel+mythtv@…]

The "Wait for SEQ Header" was always unchecked here, but run into that bug really often on one station. However, this station doesn't broadcast anymore via DVB-T.

[simonf]

I know this may be a silly question but when the back end is asked to start recording the new program, on a program break, is it seen as a full request IE does it retune and resend the channel info to the demuxer. if this is the case certain chanels with a low signal would take longer to lock. (especialy with dvb) I remember when I unchecked "Wait for SEQ Header" I also made a new video source for each of my tuners one tuner in particular took a long time to lock on Channel5 uk DVB-t so i removed that transmitter from the video source for that card. Also I bought a 3 way ariel amp and all the dvb cards have there own signal input before the signal used to go into one card and out then into the next card. This reduced the number of artifacts (blips) on the screen, dvb is very sensitive to poor signal strength. One thing that realy does show this up is to reduce the signal time out in the scan to say 1.5 seconds 1500ms and do a scan for channels without the booster i get 2 muxes (BBC ones) and with it i get all the muxes. (QED) thus if it does do a retune / re-demux every time it gets bo a program break it would take over 1.5 seconds to relock. The other thing i find interesting is that a) some of us have problems which manifest themselves more on given channels and b) some people dont have the same problem running almost identical/ identical hardware and ditros thus surely the problem has got to have something to do with eiter the setup or the boxes environment eg the signal strength etc.

[Hadley Rich <hads@…>]

FWIW I've just started seeing this bug. I don't know exactly where it started happening but it was somewhere around the ffmpeg sync (no idea if it's related at all, I just know it was somewhere around there).

I see the video stop on a frame and the following type of thing in the log.

2007-07-02 16:00:08.279 NVP: prebuffering pause
2007-07-02 16:00:08.909 RingBuf(/mnt/livetv/1071_20070702160000.mpg): Waited 1.0 seconds for data to become available...
2007-07-02 16:00:08.909 Checking to see if there's a new livetv program to switch to..
2007-07-02 16:00:09.937 RingBuf(/mnt/livetv/1071_20070702160000.mpg): Waited 2.0 seconds for data to become available...
2007-07-02 16:00:09.937 Checking to see if there's a new livetv program to switch to..
2007-07-02 16:00:10.063 NVP: Prebuffer wait timed out 10 times.
2007-07-02 16:00:11.865 NVP: Prebuffer wait timed out 10 times.

...and so on. The issue is intermittent.

If there's any info I can provide I'd be more than happy to.

[ngdreas@…]

Well, this is another "me too". I have three tuner cards, two are hardware mpeg (ivtv), and one is a simple framegrabber (saa7134). The problem only shows when I use one of the hardware mpeg cards.

[Hadley Rich <hads@…>]

The post by ngdreas@… made me think about it and I believe this only occurs on my ivtv card also.

I've just today reverted to [13654] (immediately prior to the ffmpeg resync) and have had LiveTV running on the ivtv card for 5-6 hours without any freezes.

So it appears to be related to, or introduced since that for me at least.

[vdr@…]

Same problem for me too with my ivtv card. Running revision 13654 works fine. Any newer revisions have the problem.

[eric.bosch@…]

I also have this issue. I have 3 ivtv tuners, one in the master backend server and two in a slave server. The observations I have made is that when it switches to a new ring buffer at the beginning of the next program, the frontend fails to sync, in that it is waiting for prebuffer messages which may not be showing up. I have checked to see that the ringbuffer file exists, and it does, and can be played with mplayer. If I leave the frontend alone (in the hung state), and wait for the next show transition, it actually recovers and starts playing again. I hope this rings a bell with somebody, but it seems to be a simple problem. Just not simple to find it...

[Nick Morrott <<knowledgejunkie [at] gmail [dot] com>>]

Sadly another me-too with LiveTV/ivtv card. Relevant mythackend/frontend log data follows with some general wonderings afterwards:

Backend:

2007-07-17 22:19:21.912 TVRec(6): HW Tuner: 6->6
2007-07-17 22:19:22.943 ret_pid(0) child(2717) status(0x0)
2007-07-17 22:19:23.951 ret_pid(0) child(2717) status(0x0)
2007-07-17 22:19:24.959 ret_pid(0) child(2717) status(0x0)
2007-07-17 22:19:25.967 ret_pid(0) child(2717) status(0x0)
2007-07-17 22:19:26.971 ret_pid(2717) child(2717) status(0x0)
2007-07-17 22:19:26.972 External Tuning program exited with no error
2007-07-17 22:19:27.299 MPEGRec(/dev/video1) Warning: Stream type 'DVD-Special 2'
                        is not supported by ivtv driver, using 'DVD' instead.
2007-07-17 22:19:27.308 MPEGRec(/dev/video1) Warning: VBI recording with broken drivers.
                        Upgrade to ivtv 0.10.0 if you experience problems.
2007-07-17 22:19:41.900 ret_pid(0) child(2746) status(0x0)
2007-07-17 22:19:42.915 ret_pid(0) child(2746) status(0x0)
2007-07-17 22:19:43.920 ret_pid(0) child(2746) status(0x0)
2007-07-17 22:19:44.928 ret_pid(0) child(2746) status(0x0)
2007-07-17 22:19:45.932 ret_pid(2746) child(2746) status(0x0)
2007-07-17 22:19:45.933 External Tuning program exited with no error
2007-07-17 22:19:45.951 Finished recording Search For The SS Republic: channel 4032
2007-07-17 22:19:45.958 scheduler: Finished recording: Search For The SS Republic: channel 4032
2007-07-17 22:19:46.102 Finished recording Search For The SS Republic: channel 4032
[mpeg @ 0x182aa0]Parser not found for Codec Id: 94210 !
0: start_time: -9223372036854.775 duration: -9223372036854.775
1: start_time: -9223372036854.775 duration: -9223372036854.775
2: start_time: -9223372036854.775 duration: -9223372036854.775
stream: start_time: -9223372036854.775 duration: -9223372036854.775 bitrate=6256 kb/s
0: start_time: 0.036 duration: 1.030
1: start_time: 12.364 duration: 1.066
2: start_time: 0.025 duration: 1.004
stream: start_time: 0.276 duration: 148.945 bitrate=383 kb/s
2007-07-17 22:19:46.205 AFD: Opened codec 0xa045ae0, id(MPEG2VIDEO) type(Video)
2007-07-17 22:19:46.207 AFD: Opened codec 0xa045380, id(MP2) type(Audio)
2007-07-17 22:19:46.227 TVRec(6): RingBufferChanged()
2007-07-17 22:19:46.236 Finished recording Search For The SS Republic: channel 4032
2007-07-17 23:00:00.852 Finished recording Law and Order: Special Victims Unit "Vulnerable": channel 4019
2007-07-17 23:00:00.859 scheduler: Last message repeated 2 times: Finished recording: Search For The SS Republic: channel 4032
2007-07-17 23:00:00.878 scheduler: Finished recording: Law and Order: Special Victims Unit "Vulnerable": channel 4019
[mpeg @ 0x182aa0]Parser not found for Codec Id: 94210 !
2007-07-17 23:00:01.295 TVRec(6): RingBufferChanged()
2007-07-17 23:00:01.383 Finished recording Law and Order: Special Victims Unit "Vulnerable": channel 4019
0: start_time: -9223372036854.775 duration: -9223372036854.775
1: start_time: -9223372036854.775 duration: -9223372036854.775
2: start_time: -9223372036854.775 duration: -9223372036854.775
stream: start_time: -9223372036854.775 duration: -9223372036854.775 bitrate=6256 kb/s
0: start_time: 1.138 duration: 217.789
1: start_time: 13.851 duration: 217.466
2: start_time: 1.103 duration: 217.801
stream: start_time: 12.252 duration: 2557.942 bitrate=4766 kb/s
2007-07-17 23:00:01.480 AFD: Opened codec 0xa1261a0, id(MPEG2VIDEO) type(Video)
2007-07-17 23:00:01.489 AFD: Opened codec 0xa12d440, id(MP2) type(Audio)
2007-07-17 23:01:01.897 TVRec(6): Changing from WatchingLiveTV to None
2007-07-17 23:01:02.145 Finished recording Law and Order: Criminal Intent "Happy Family": channel 4019
2007-07-17 23:01:02.155 scheduler: Last message repeated 1 times: Finished recording: Law and Order: Special Victims Unit "Vulnerable": chan
nel 4019
2007-07-17 23:01:02.161 scheduler: Finished recording: Law and Order: Criminal Intent "Happy Family": channel 4019

Frontend:

2007-07-17 23:00:18.827 NVP: prebuffering pause
2007-07-17 23:00:19.158 RingBuf(/recordings/4019_20070717230000.mpg): Waited 1.0 seconds for data to become available...
2007-07-17 23:00:19.158 Checking to see if there's a new livetv program to switch to..
2007-07-17 23:00:20.182 RingBuf(/recordings/4019_20070717230000.mpg): Waited 2.0 seconds for data to become available...
2007-07-17 23:00:20.182 Checking to see if there's a new livetv program to switch to..
2007-07-17 23:00:20.502 NVP: Prebuffer wait timed out 10 times.
2007-07-17 23:00:22.142 NVP: Prebuffer wait timed out 10 times.
2007-07-17 23:00:22.230 RingBuf(/recordings/4019_20070717230000.mpg): Waited 4.0 seconds for data to become available...
2007-07-17 23:00:22.230 Checking to see if there's a new livetv program to switch to..
2007-07-17 23:00:23.782 NVP: Prebuffer wait timed out 10 times.
2007-07-17 23:00:25.422 NVP: Prebuffer wait timed out 10 times.
2007-07-17 23:00:26.330 RingBuf(/recordings/4019_20070717230000.mpg): Waited 8.0 seconds for data to become available...
2007-07-17 23:00:26.330 Checking to see if there's a new livetv program to switch to..
2007-07-17 23:00:27.062 NVP: Prebuffer wait timed out 10 times.
2007-07-17 23:00:28.702 NVP: Prebuffer wait timed out 10 times.
2007-07-17 23:00:30.342 NVP: Prebuffer wait timed out 10 times.
2007-07-17 23:00:31.982 NVP: Prebuffer wait timed out 10 times.

LiveTV was started at 22:19 and the channel was initially set to The History Channel (program: Search For The SS Republic). We then changed channel successfully to Hallmark to catch Law and Order (program: Law and Order: Special Victims Unit "Vulnerable") which was scheduled to finish at 2300. At the scheduler program boundary, the log showed:

2007-07-17 23:00:00.852 Finished recording Law and Order: Special Victims Unit "Vulnerable": channel 4019
2007-07-17 23:00:00.859 scheduler: Last message repeated 2 times: Finished recording: Search For The SS Republic: channel 4032

Note the erroneous inclusion of the program that was recorded when LiveTV was entered, but finished recording some 41 minutes before.

At this time, video playback froze and we backed out of LiveTV, which took several seconds after pressing Back/Exit?. The logfile showed scheduler information for both programs that spanned the failed program boundary:

2007-07-17 23:01:02.145 Finished recording Law and Order: Criminal Intent "Happy Family": channel 4019
2007-07-17 23:01:02.155 scheduler: Last message repeated 1 times: Finished recording: Law and Order: Special Victims Unit "Vulnerable": chan
nel 4019

It is interesting that again, 2 programs are listed as having finished recording at the same time, over a minute after the actual program change, although unlike above, these were the two consecutive programs spanning the program boundary. Why the scheduler thought it was still recording The History Channel until 2300 is anyone's guess.

Needless to say, WAF has been dramatically lowered since this bug was introduced...

Nick

[Shane Shrybman <gnome42@…>]

I found a problem that causes the wrong position map to be deleted. Try this patch (mythtv_move_ResetForNewFile.diff) and see if it helps.

Shane

[Hadley Rich <hads@…>]

I just tried ResetForNewFile? on one of my frontends and it didn't help the issue unfortunately.

[eric.bosch@…]

I just tried that patch as well, and there actually may be slight improvement. It just successfully transitioned one program. It did so last night as well, but stalled out 5 minutes later. Perhaps something else going on with my system, but I will continue to test.

[eric.bosch@…]

Frontend Log file during failed program transition

[anonymous]

I just went through another program transition, and it continued to play for about a minute, and then the video halted, and mythfrontend CPU usage went to 95%. At that point, I exited, and after a several second wait, CPU usage went back down, and the menu returned. See mythlog.txt attached above.

[anonymous]

Replying to Shane Shrybman <gnome42@gmail.com>:

I found a problem that causes the wrong position map to be deleted. Try this patch (mythtv_move_ResetForNewFile.diff) and see if it helps.

Shane

Sadly no improvement with this patch using my ivtv source. From the backend log it appears the correct ringbuffer file is being requested - and the recordings directory certainly contains it (it grows in size until I back out of frozen Live TV).

From the backend log around a program boundary (044000)followed by a freeze:

2007-07-24 04:40:00.209 TVRec(4): SwitchLiveTVRingBuffer(discont 0, set_rec 1)
2007-07-24 04:40:00.214 TVRec(4): GetProgramRingBufferForLiveTV()
2007-07-24 04:40:00.238 Scheduler: FindNextLiveTVDir: next dir is '/recordings'
2007-07-24 04:40:00.373 ProgramInfo: StartedRecording: Recording to '/recordings/4021_20070724044000.mpg'
2007-07-24 04:40:00.491 TVRec(4): StartedRecording(0xa178010) fn(/recordings/4021_20070724044000.mpg)
2007-07-24 04:40:00.572 TVRec(4): FinishedRecording(Watercolours with Charles Evans) in recgroup: LiveTV
2007-07-24 04:40:00.639 Chain: Updated endtime for '4021_20070724041655' to 20070724044000
2007-07-24 04:40:00.662 Finished recording Watercolours with Charles Evans: channel 4021
2007-07-24 04:40:00.683 scheduler: Finished recording: Watercolours with Charles Evans: channel 4021
2007-07-24 04:40:00.685 SG(LiveTV): Unable to find storage group 'LiveTV', trying 'Default' group!
2007-07-24 04:40:00.687 SG(Default): FindRecordingFile: Searching for '4021_20070724041655.mpg'
2007-07-24 04:40:00.688 SG(Default): FindRecordingDir: Checking '/recordings'
2007-07-24 04:40:00.688 SG(Default): FindRecordingFile: Found '/recordings/4021_20070724041655.mpg'
2007-07-24 04:40:00.689 ProgramInfo: GetPlaybackURL: File is local: '/recordings/4021_20070724041655.mpg'
2007-07-24 04:40:00.691 Preview: 'myth://192.168.1.1:6543/4021_20070724041655.mpg' is not local,
                        replacing with '/recordings/4021_20070724041655.mpg', which is local.
2007-07-24 04:40:00.732 Chain: Appended@4 '4021_20070724044000'
[mpeg @ 0x185520]2007-07-24 04:40:01.251 TVRec(4): SetFlags(RingBufferReady,) -> FrontendReady,RunMainLoop,CancelNextRecording,AskAllowRecor
ding,RecorderRunning,RingBufferReady,
2007-07-24 04:40:01.258 TVRec(4): !has_rec(1) !rec_soon(1) curRec(0x9f16698) starttm(2007-07-24T04:16:55)
2007-07-24 04:40:01.262 TVRec(4): Enabling Full LiveTV UI.
Parser not found for Codec Id: 94210 !
0: start_time: -9223372036854.775 duration: -9223372036854.775
1: start_time: -9223372036854.775 duration: -9223372036854.775
2: start_time: -9223372036854.775 duration: -9223372036854.775
stream: start_time: -9223372036854.775 duration: -9223372036854.775 bitrate=6256 kb/s
0: start_time: 57.467 duration: 125.154
1: start_time: 3573.291 duration: 124.781
2: start_time: 57.435 duration: 125.148
stream: start_time: 638.172 duration: 40451.510 bitrate=173 kb/s
2007-07-24 04:40:01.335 AFD: Opened codec 0xa25b4c0, id(MPEG2VIDEO) type(Video)
2007-07-24 04:40:01.348 AFD: Opened codec 0x9fa0650, id(MP2) type(Audio)
2007-07-24 04:40:01.682 RecBase(/dev/video0): SetRingBuffer(0x9f5cc40) '/recordings/4021_20070724044000.mpg'
2007-07-24 04:40:01.686 TVRec(4): RingBufferChanged()
2007-07-24 04:40:01.691 TVRec(4): FinishedRecording(Watercolours with Charles Evans) in recgroup: LiveTV
2007-07-24 04:40:01.693 Chain: Updated endtime for '4021_20070724041655' to 20070724044001
2007-07-24 04:40:01.729 Finished recording Watercolours with Charles Evans: channel 4021
2007-07-24 04:47:45.732 StopLiveTV(void) curRec: 0x9f16698 pseudoRec: 0
2007-07-24 04:47:45.746 TVRec(4): Changing from WatchingLiveTV to None
2007-07-24 04:47:45.747 TVRec(4): ClearFlags(FrontendReady,CancelNextRecording,) -> RunMainLoop,AskAllowRecording,RecorderRunning,RingBuffer
Ready,
2007-07-24 04:47:45.748 TVRec(4): SetFlags(AskAllowRecording,) -> RunMainLoop,AskAllowRecording,RecorderRunning,RingBufferReady,
2007-07-24 04:47:45.748 TVRec(4): Request: Program(no) channel() input() flags(KillRec,KillRingBuffer,)
2007-07-24 04:47:45.788 TVRec(4): ClearFlags(RecorderRunning,) -> RunMainLoop,AskAllowRecording,RingBufferReady,
2007-07-24 04:47:45.821 TVRec(4): FinishedRecording(The Joy of Painting) in recgroup: LiveTV
2007-07-24 04:47:45.822 Chain: Updated endtime for '4021_20070724044000' to 20070724044745
2007-07-24 04:47:45.845 Finished recording The Joy of Painting "A Perfect Winter Day": channel 4021
2007-07-24 04:47:45.851 scheduler: Last message repeated 1 times: Finished recording: Watercolours with Charles Evans: channel 4021
2007-07-24 04:47:45.854 scheduler: Finished recording: The Joy of Painting "A Perfect Winter Day": channel 4021
2007-07-24 04:47:45.858 TVRec(4): ClearFlags(RecorderRunning,) -> RunMainLoop,AskAllowRecording,RingBufferReady,
2007-07-24 04:47:45.860 TVRec(4): Tearing down RingBuffer
2007-07-24 04:47:45.861 TVRec(4): ClearFlags(PENDINGACTIONS,) -> RunMainLoop,AskAllowRecording,RingBufferReady,

From the frontend log

2007-07-24 04:40:00.239 read  <- 20 53      BACKEND_MESSAGE[]:[]QUERY_NEXT_LIVETV_DIR 4[]:[]empty
2007-07-24 04:40:00.240 MythEvent: QUERY_NEXT_LIVETV_DIR 4
2007-07-24 04:40:00.508 read  <- 20 51      BACKEND_MESSAGE[]:[]RECORDING_LIST_CHANGE[]:[]empty
2007-07-24 04:40:00.510 MythEvent: RECORDING_LIST_CHANGE
2007-07-24 04:40:00.630 NVP: 50400 interlaced frames seen.
2007-07-24 04:40:00.647 read  <- 20 85      BACKEND_MESSAGE[]:[]LIVETV_CHAIN UPDATE live-homer.home-2007-07-2...
2007-07-24 04:40:00.647 MythEvent: LIVETV_CHAIN UPDATE live-homer.home-2007-07-24T04:06:06
'video_output' mean = '39960.44', std. dev. = '3163.89', fps = '25.02'
2007-07-24 04:40:00.805 read  <- 20 85      BACKEND_MESSAGE[]:[]LIVETV_CHAIN UPDATE live-homer.home-2007-07-2...
2007-07-24 04:40:00.805 MythEvent: LIVETV_CHAIN UPDATE live-homer.home-2007-07-24T04:06:06
2007-07-24 04:40:00.863 LiveTVChain(live-homer.home-2007-07-24T04:06:06): ReloadAll(): Added new recording
2007-07-24 04:40:00.863 Resyncing position map. posmapStarted = 0 livetv(1) watchingRec(0)
2007-07-24 04:40:01.111 Position map filled from DB to: 2888
2007-07-24 04:40:01.112 SyncPositionMap watchingrecording, from DB: 2888 entries
2007-07-24 04:40:01.112 SyncPositionMap watchingrecording no entries from encoder, try DB
2007-07-24 04:40:01.250 Position map filled from DB to: 2891
2007-07-24 04:40:01.250 SyncPositionMap watchingrecording total: 2891 entries
2007-07-24 04:40:01.251 SyncPositionMap, new totframes: 34692, new length: 1387, posMap size: 2891
2007-07-24 04:40:01.263 read  <- 20 46      BACKEND_MESSAGE[]:[]LIVETV_WATCH 4 0[]:[]empty
2007-07-24 04:40:01.263 MythEvent: LIVETV_WATCH 4 0
2007-07-24 04:40:01.695 read  <- 20 85      BACKEND_MESSAGE[]:[]LIVETV_CHAIN UPDATE live-homer.home-2007-07-2...
2007-07-24 04:40:01.695 MythEvent: LIVETV_CHAIN UPDATE live-homer.home-2007-07-24T04:06:06
2007-07-24 04:40:02.085 LiveTVChain(live-homer.home-2007-07-24T04:06:06): SwitchTo(3)
2007-07-24 04:40:02.085 LiveTVChain(live-homer.home-2007-07-24T04:06:06): Entry@3: '4021_20070724044000'
2007-07-24 04:40:02.089 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(2602KB) vfl(30) frh(83) ne:0
2007-07-24 04:40:02.105 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(2602KB) vfl(30) frh(83) ne:0
2007-07-24 04:40:02.117 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(2569KB) vfl(30) frh(82) ne:0
2007-07-24 04:40:02.133 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(2569KB) vfl(30) frh(82) ne:0
2007-07-24 04:40:02.162 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(2536KB) vfl(30) frh(81) ne:0
2007-07-24 04:40:02.177 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(2536KB) vfl(30) frh(81) ne:0
2007-07-24 04:40:02.200 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(2536KB) vfl(30) frh(81) ne:0
2007-07-24 04:40:02.213 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(2536KB) vfl(30) frh(81) ne:0
2007-07-24 04:40:02.229 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(2536KB) vfl(30) frh(81) ne:0

etc

2007-07-24 04:40:05.505 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(472KB) vfl(30) frh(15) ne:0
2007-07-24 04:40:05.530 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(472KB) vfl(30) frh(15) ne:0
2007-07-24 04:40:05.551 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(472KB) vfl(30) frh(15) ne:0
2007-07-24 04:40:05.569 NVP: IsReallyNearEnd() br(782KB) fps(24) sz(439KB) vfl(30) frh(14) ne:1
2007-07-24 04:40:05.569 SwitchToProgram(void)
2007-07-24 04:40:05.574 write -> 18 33      MESSAGE[]:[]RECORDING_LIST_CHANGE
2007-07-24 04:40:05.574 read  <- 18 2       OK
2007-07-24 04:40:05.575 read  <- 20 51      BACKEND_MESSAGE[]:[]RECORDING_LIST_CHANGE[]:[]empty
2007-07-24 04:40:05.575 MythEvent: RECORDING_LIST_CHANGE
2007-07-24 04:40:05.577 write -> 18 33      MESSAGE[]:[]RECORDING_LIST_CHANGE
2007-07-24 04:40:05.582 read  <- 20 51      BACKEND_MESSAGE[]:[]RECORDING_LIST_CHANGE[]:[]empty
2007-07-24 04:40:05.582 MythEvent: RECORDING_LIST_CHANGE
2007-07-24 04:40:05.578 read  <- 18 2       OK
2007-07-24 04:40:05.586 SG(LiveTV): Unable to find storage group 'LiveTV', trying 'Default' group!
2007-07-24 04:40:05.587 SG(Default): FindRecordingFile: Searching for '4021_20070724044000.mpg'
2007-07-24 04:40:05.587 SG(Default): FindRecordingDir: Checking '/recordings'
2007-07-24 04:40:05.587 SG(Default): FindRecordingFile: Found '/recordings/4021_20070724044000.mpg'
2007-07-24 04:40:05.588 ProgramInfo: GetPlaybackURL: File is local: '/recordings/4021_20070724044000.mpg'
2007-07-24 04:40:05.588 RingBuf(/recordings/4021_20070724041655.mpg): OpenFile(/recordings/4021_20070724044000.mpg, 10)
2007-07-24 04:40:05.588 RingBuf(/recordings/4021_20070724044000.mpg): CalcReadAheadThresh(2967649640 KB)
                         -> threshhold(64 KB) min read(0 KB) blk size(32 KB)
2007-07-24 04:40:05.588 RingBuf(/recordings/4021_20070724044000.mpg): CalcReadAheadThresh(117570023 KB)
                         -> threshhold(64 KB) min read(0 KB) blk size(32 KB)
2007-07-24 04:40:05.649 Avg read interval was 184 msec. 64K block size
2007-07-24 04:40:05.665 Avg read interval was 197 msec. 96K block size
2007-07-24 04:40:05.684 Avg read interval was 197 msec. 128K block size
2007-07-24 04:40:05.701 Avg read interval was 197 msec. 160K block size
2007-07-24 04:40:05.913 Avg read interval was 195 msec. 192K block size
2007-07-24 04:40:06.333 FileChangedCallback
2007-07-24 04:40:06.382 Resyncing position map. posmapStarted = 0 livetv(1) watchingRec(1)
2007-07-24 04:40:06.383 Position map filled from DB to: 1
2007-07-24 04:40:06.383 SyncPositionMap watchingrecording, from DB: 1 entries
2007-07-24 04:40:06.383 write -> 21 39      QUERY_RECORDER 4[]:[]GET_FRAMES_WRITTEN
2007-07-24 04:40:06.384 read  <- 21 8       0[]:[]96
2007-07-24 04:40:06.384 Filling position map from 2 to 8
2007-07-24 04:40:06.384 write -> 21 50      QUERY_RECORDER 4[]:[]FILL_POSITION_MAP[]:[]2[]:[]8
2007-07-24 04:40:06.385 read  <- 21 203     0[]:[]2[]:[]0[]:[]602220[]:[]0[]:[]3[]:[]0[]:[]808208[]:[]0[]:[]4...
2007-07-24 04:40:06.385 Position map filled from Encoder to: 8
2007-07-24 04:40:06.385 SyncPositionMap watchingrecording total: 8 entries
2007-07-24 04:40:06.385 SyncPositionMap, new totframes: 96, new length: 3, posMap size: 8
2007-07-24 04:40:07.812 NVP: prebuffering pause
2007-07-24 04:40:07.812 NVP: Waiting for prebuffer.. 0 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:07.812 WriteAudio: buffer underrun
2007-07-24 04:40:07.991 NVP: Waiting for prebuffer.. 1 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:08.153 NVP: Waiting for prebuffer.. 2 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:08.336 NVP: Waiting for prebuffer.. 3 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:08.342 RingBuf(/recordings/4021_20070724044000.mpg): Waited 1.0 seconds for data to become available...
2007-07-24 04:40:08.342 Checking to see if there's a new livetv program to switch to..
2007-07-24 04:40:08.498 NVP: Waiting for prebuffer.. 4 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:08.681 NVP: Waiting for prebuffer.. 5 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:08.863 NVP: Waiting for prebuffer.. 6 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:09.026 NVP: Waiting for prebuffer.. 7 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:09.208 NVP: Waiting for prebuffer.. 8 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:09.365 RingBuf(/recordings/4021_20070724044000.mpg): Waited 2.0 seconds for data to become available...
2007-07-24 04:40:09.365 Checking to see if there's a new livetv program to switch to..
2007-07-24 04:40:09.370 NVP: Waiting for prebuffer.. 9 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:09.533 NVP: Prebuffer wait timed out 10 times.
2007-07-24 04:40:09.533 NVP: Waiting for prebuffer.. 0 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:09.715 NVP: Waiting for prebuffer.. 1 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:09.878 NVP: Waiting for prebuffer.. 2 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:10.063 NVP: Waiting for prebuffer.. 3 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:10.243 NVP: Waiting for prebuffer.. 4 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:10.405 NVP: Waiting for prebuffer.. 5 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:10.588 NVP: Waiting for prebuffer.. 6 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:10.750 NVP: Waiting for prebuffer.. 7 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:10.933 NVP: Waiting for prebuffer.. 8 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:11.115 NVP: Waiting for prebuffer.. 9 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:11.277 NVP: Prebuffer wait timed out 10 times.
2007-07-24 04:40:11.278 NVP: Waiting for prebuffer.. 0 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:11.413 RingBuf(/recordings/4021_20070724044000.mpg): Waited 4.0 seconds for data to become available...
2007-07-24 04:40:11.413 Checking to see if there's a new livetv program to switch to..

The file /recordings/4021_20070724044000.mpg was being recorded normally whilst the frontend was frozen.

The frontend log then continued with the following as things timed out:

2007-07-24 04:40:21.748 NVP: Prebuffer wait timed out 10 times.
2007-07-24 04:40:21.766 NVP: Waiting for prebuffer.. 0 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:21.929 NVP: Waiting for prebuffer.. 1 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:22.111 NVP: Waiting for prebuffer.. 2 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:22.274 NVP: Waiting for prebuffer.. 3 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:22.456 NVP: Waiting for prebuffer.. 4 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:22.639 NVP: Waiting for prebuffer.. 5 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:22.801 NVP: Waiting for prebuffer.. 6 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:22.984 NVP: Waiting for prebuffer.. 7 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:23.146 NVP: Waiting for prebuffer.. 8 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:23.308 NVP: Waiting for prebuffer.. 9 AAAAuAAAAAAAAAAAAaAALAAAAAAAAAA
2007-07-24 04:40:23.444 RingBuf(/recordings/4021_20070724044000.mpg) Error: Waited 16 seconds for data, aborting.
[mpeg2video @ 0x5273a8]ac-tex damaged at 34 34
[mpeg2video @ 0x5273a8]Warning MVs not available
2007-07-24 04:40:23.462 Ignoring livetv eof in decoder loop
2007-07-24 04:40:23.472 NVP: Prebuffer wait timed out 10 times.
2007-07-24 04:40:23.491 NVP: Waiting for prebuffer.. 0 AAALUAAAAAAAAAAAAAAAuAAAAAAAAAA
2007-07-24 04:40:23.512 Avg read interval was 195 msec. 64K block size
2007-07-24 04:40:23.512 Avg read interval was 196 msec. 96K block size
2007-07-24 04:40:23.512 Avg read interval was 196 msec. 128K block size
2007-07-24 04:40:23.513 Avg read interval was 196 msec. 160K block size
2007-07-24 04:40:23.513 Avg read interval was 196 msec. 192K block size
2007-07-24 04:40:23.513 Avg read interval was 196 msec. 224K block size

The "Ignoring livetv eof in decoder loop" looks ominous. The log was just filling up with this information repeated over and over. Looks like a nice quick way of filling a partition!

Nick

[mythtv at miwers dot dk]

Shane's patch didn't do the trick for me either. However, I also tested with Tino's patch in order to reproduce the error faster (every 2 minutes, for "Unknown" shows), and here's my findings:

I can only reproduce this problem on my IVTV tuners. It's a Hauppauge PVR500 dual tuner card.

I also have a WinFast? DTV2000H, which is a hybrid analogue/digital tuner. This card uses some different modules (not IVTV), and using this card will not reproduce this error.

So...

card1: IVTV: PVR500-1: reproducible
card2: IVTV: PVR500-2: reproducible
card3: V4L: DTV2000 A: not reproducible
card4: DVB: DTV2000 D: not reproducible

A theory of mine is, that the MPEG2 stream of the ivtv tuner is different than that generated by the DVB card, and may contain some "bugs" that the frontend player can't handle...

Another theory (and an educated guess on mythtv recording): During channel change, the card is reset, and a new MPEG stream with headers and stuff is generated. But during program change on the same channel, the card is not reset, but recording happens to a new file. Won't the player be missing some MPEG headers, which causes it to freeze?

Maybe those two theories combined are the reason that only my IVTV tuners freeze and the DVB tuner does not?

I have kept two recordings for each tuner type, if someone would like to make a comparisson between them. First recording when entering the channel and the following file on program change. Contact me by email for a link to the files (few hundred megs)

Miwer

[anonymous]

I have the same problem with my Hauppauge PVR500 after my last update to version 14022.

[eric.bosch@…]

It appears that the ticket was not updated with a fix for IVTV users. As it turns out, this problem applies to the ivtv driver in that it has a continuous stream on program transition, where apparently DVB card types do not. A fix that worked for me, as well as others is to change 1 line of code in /libs/libmythtv/tv_rec.cpp, line 1310 in current trunk, from: SwitchLiveTVRingBuffer(false, true); to SwitchLiveTVRingBuffer(true, true);

[Miwer]

Just to follow up on Eric's post...

It's not an actual fix, but rather a temporary workaround.

[anonymous]

Replying to Miwer:

Just to follow up on Eric's post...

It's not an actual fix, but rather a temporary workaround.

Correct. I appreciate the correction, just wanted to make sure this workaround was documented in the ticket.

[anonymous]

Will Eric's temporary workaround work with a system with multiple IVTV cards and DVB cards?

[eric.bosch@…]

Replying to anonymous:

Will Eric's temporary workaround work with a system with multiple IVTV cards and DVB cards?

Actually, I cannot take credit for the workaround, other than just posting it for others with the same problem. I simply had it in an email I received, but an any rate, it will certainly work on multiple IVTV cards, but I cannot verify DVB card operation. It might be a good test just to see if it does, perhaps then that will indicate a need to add functionality to identify the stream type.

[anonymous]

Working with 2 pvr-250 cards and a hdhomerun. Running reasonably current trunk.

[rob+mythtv@…]

Replying to eric.bosch@comcast.net:

A fix that worked for me, as well as others is to change 1 line of code in /libs/libmythtv/tv_rec.cpp, line 1310 in current trunk, from:

SwitchLiveTVRingBuffer(false, true); to SwitchLiveTVRingBuffer(true, true);

I have two backends, both with PVR-250 which have had the video image frequently freezing when the guide indicated a program change. I'd had the problem while following SVN for several months. The above fix applied to SVN r14193 has corrected it.

[Paul]

I've had no end of trouble with LiveTV freezing and can also confirm the issue has been rectified with the 'SwitchLiveTVRingbuffer' workaround.

[Tom Dexter <digitalaudiorock@…>]

I took a chance and tried implementing the SwitchLiveTVRingbuffer workaround on 0-20-fixes (0.20.2), and after several days it appears to be working fine. I used to get frequent lockups and 100% cpu changing from one show to the next. Not only do I not get them any more, but the switch from one show to another, which often took a few seconds even if it didn't lock up, is much faster, with just a slight hesitation.

Note that in 0.20.2 the change is on line 1333, and changes:

SwitchLiveTVRingBuffer();

...which defaults to (false, true) to:

SwitchLiveTVRingBuffer(true, true);

[taco_mel@…]

I'll add another "works for me" for this workaround. Setup is a Hauppauge PVR-500 and after patching my front end and back end (svn 14446) this eliminates the hang on a show change, reducing it to just the normal shudder when first selecting a channel.

[skd5aner@…]

I have not tried this workaround yet, but my wife happily reminded me that she cant watch live TV on the mythbox without it freezing when a show is over. Unfortunantly, anytime she wants to watch live TV, she has to go to the STB to do so. Is this "workaround" good enough to commit into trunk or does a more permantent fix need to be developed? You don't see too many tickets that have been open for a year with 74+ replies.

[eric.bosch@…]

I can confirm I have had no issues whatsoever with my IPTV cards. The question is, does this also work with non-IPTV cards, and so far I haven't heard anything stating that it doesn't.

[Tom Dexter <digitalaudiorock@…>]

The fix is working fine for me with pcHDTV HD-5500 cards (used only for digital OTA broadcasts).

[andreas.koester@…]

I tried the patch one week ago (rev 14374) on a system with two Technisat SkyStar2 DVB cards. Since then the freezing has disappeared. Sometimes the TV freezes for 1..10 seconds when the show ends, but then it continues without user interaction.

[stuartm]

Thanks to Shane we've tracked at least one cause of this problem to a url_fseek added to mpegps_read_pes_header() (mpeg.c) during the ffmpeg resync(s). It's a frontend bug.

During continuous transitions we attempt to give the impression to avformatdecoder that it is still working on the same file, this avoids glitches in playback associated with reseting the decoder. This means the file pointer used in mpeg.c is out of sync with the actual position in the file following a transition. When mpegps_read_pes_header() encounters an error it seeks back to the last good position and tries again, calling url_fseek with the wrong position information. This causes RingBuffer::Seek to seek past the EOF.

Shane and I are reluctant to touch avformatdecoder because of the problems that causes with ffmpeg resync plus the unforeseen affects it might have on playback of unusual streams. The url_fseek change has previously been reverted by Daniel after a previous resync because at that time it caused problems with DVD playback. Another solution might mean sanity checking the position given to RingBuffer::Seek() and unless anyone has a better idea that's what I'm going to work on for now.

[stuartm]

Attaching a fix for the issue which is shown in the logs of Tino and Miwer. The problem in Eric's log is different.

It may not be the solution we finally choose. This idea comes from Janne. It has been confirmed to work, but I'd like to see whether it causes other problems for anyone.

[stuartm]

One potential fix

[eric.bosch@…]

I patched the file and from all indications, it actually seems to have fixed the issue. I removed the workaround previously applied, and so it livetv has successfully transitioned all programs.

[Joe Ripley <vitaminjoe@…>]

The 2335_fix.diff posted by Stuart works perfectly for me. It solved all my 'NVP: prebuffering pause' problems with LiveTV. Previously, LiveTV would be choppy for 30 seconds or so when it first started... my workaround was to pause LiveTV for about 10 seconds and then begin watching.

But, no more! Thanks Stuart!

-- Joe Ripley vitaminjoe@…

[Hadley Rich <hads@…>]

I've been running with this patch for about 8 hours or so and everything is running smoothly. Much the same behaviour as reported by Joe Ripley above.

I haven't noticed any side effects so for.

Many thanks to all those involved in working on a providing this potential fix.

[peacekeeper@…]

I applied this patch and it has fixed my stutter at startup and Prebuffer pauses issues. I checkout SVN 14489 compiled without patch, had the stutter. Then I applied the patch recompiled and all works great. Thank you for this patch!

[Shane Shrybman <gnome42@…>]

Updated patch. Please test with non-livetv files

[Shane Shrybman <gnome42@…>]

2335_fix_2.diff is an updated patch.

Please try it out with non-livetv files (eg. recordings and videos). Specifically check to see if it breaks seeking in any of these scenarios. Thanks.

[eric.bosch@…]

I tested watching several recorded programs last night and saw no issues at all, but this was with the first 2335_fix.diff file, and sometime during the night, my power supply in the computer shot craps, so I get to deal with that before I can test further. Thanks.

[wiz561@…]

FYI, I was running into the same exact problem with 14489. This occured after EVERY single show, no matter what.

I applied the 2335_fix_2.diff diff and, so far, I have had ZERO problems! Hopefully this does the trick!

Thank you so much!

[Shane Shrybman <gnome42@…>]

There is another problem that will result in lost position maps after show transitions and hence break seeking for DTV recorders. Please apply the patch from ticket #3963 as well as 2335_fix_2.diff. Thanks

[Ben Kohler <bkohler@…>]

this patch has been working wonderfully for me for a few weeks now. any chance of getting this into trunk? for me, livetv is basically unusable without it.

[Janne Grunau]

updated fix. set is_streamed only for DVD and LiveTV with posmap. DVB cards need #3963 to be fixed

[stuartm]

(In [14516]) Fix for liveTV transitions with mpeg recorders.

Thanks to Shane, Janne and everyone else who helped with debugging and the solution.

#3963 addressess a second issue with deleted positionmaps which is required to prevent seeking issues with this change.

Fixes #2335

[stuartm]

(In [14522]) Drop the positionmap check added as part of the fix for #2335 in [14516]. This is mostly redundant once #3963 is fixed since a LiveTV recording should always have a postionmap.

Moving the point at which we loaded the positionmap caused a problem with the frame counts for recordings because we hadn't yet looked at the stream for the framerate.

Refs #2335