[mythtv-commits] Ticket #2335: LiveTV hangs when a recording is finished and a new on starts (no channel change)

Tue Jun 5 22:41:16 UTC 2007

#2335: LiveTV hangs when a recording is finished and a new on starts (no channel
change)
-----------------------------------------+----------------------------------
 Reporter:  tino.keitel+mythtv at tikei.de  |        Owner:  ijr     
     Type:  defect                       |       Status:  reopened
 Priority:  minor                        |    Milestone:  unknown 
Component:  mythtv                       |      Version:  head    
 Severity:  medium                       |   Resolution:          
-----------------------------------------+----------------------------------

Comment(by 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

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/2335#comment:49>
MythTV <http://svn.mythtv.org/trac>
MythTV