LinHES Forums
http://forum.linhes.org/

Prog Boundary-Error Was encountered while displaying video
http://forum.linhes.org/viewtopic.php?f=6&t=15564		 Page 1 of 1
Author:  declanh [ Sat Jun 09, 2007 5:08 am ]
Post subject:  Prog Boundary-Error Was encountered while displaying video
Folks,
it seems a fair few people now are suffering this issue

Note that this issue only occurs with version of mythtv which store "livetv recordings" so if you use an older version which does not automatically save livetv recordings please dont vote here as it will skew the results.

As we still dont have a fix or workaround I'm proposing a poll to work out the scale of the issue - I'd be grateful if you could respond with to one of the answers below and then add the details about your setup (if you dont want to add the deails please "vote" anyway as it will help put the problem in perspective)

Thanks for listening

Background below dotted line
-----------------------------------------------------------------------
It seems the error "Error Was encountered while displaying video" happens during LiveTV watching in knoppmyth r5e50 and some previous versions

1) its been around for at least a year
2) there does not seem to be any commonality as to what hardware config it manifests itself in - a random collection of AMD/Intel processors and variety of motherboard
3) Its reported mainly here with DVB and HDTV recording but thats not definitive
4) It seems to happen at the program boundary when the backend wants to take a new 'LiveTV recording' file and the front end attempts to open it
5) There is a suggestion that it may be that the frontend is trying to open the new recording file before its been created
6) There is a suggestion that it could be related to Mysql DB performance problems
7) Some tweaks to my.cnf were applied and seemed to help a bit but the problem is still present
8 ) Mythtv has a ticket for this http://svn.mythtv.org/trac/ticket/2335
9) Ive tried various other distros and mythtv and its happening with mythdora and ubuntu + myth - so its unlikely to be a knoppmyth issue
10) mythtv .20 changes have been applied to r5e50 with no success
11) I seems that pressing the pause button during livetv can alleviate the problem as it gives the frontend more time to open the new file - this is not a solution for the channel surfer tho.

Read the whole thread here
http://www.mysettopbox.tv/phpBB2/viewtopic.php?t=146[/b]
Author:  simonf [ Sat Jun 09, 2007 7:38 am ]
Post subject:  My posts From http://svn.mythtv.org/trac/ticket/2335
Here Are my posts from http://svn.mythtv.org/trac/ticket/2335

on how i cured this problem

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

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.
Author:  declanh [ Thu Jun 14, 2007 1:39 pm ]
Post subject: 
I Take simonfs point, that perhaps boundary transitions require a signal re-lock which perhaps takes longer on a sub-optimal aerial connection.

In my test setup im using a fairly poor indoor aerial that seems to be fair on most channels. I have however physically moved the pc to my living room which has an excellent rooftop aerial feed with a distribution amp. With my current mythbox (r5a16) id say the picture is about as good as you could expect, the only occasional glitch seems be only under very bad weather conditions. However the r51f box connected to the rooftop aerial is just as bad as my indoor aerial.

Anyone else care to comment on their aerial setup wrt this issue ?
Author:  bigB [ Sun Jun 17, 2007 9:24 pm ]
Post subject: 
Quote:
simonf:

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.


I unchecked the Wait for SEQ Header also, and have noticed a significant improvement to this problem. For reference, i have also adjusted the MySQL settings as stated in another thread.

BigB.
Page 1 of 1 All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/