Opened 18 years ago

Closed 18 years ago

#894 closed task (fixed)

DVBRec can take a while to start, keep DummyRec on

Reported by: anonymous Owned by: danielk
Priority: minor Milestone: 0.20
Component: dvb Version: head
Severity: high Keywords:
Cc: Ticket locked: no

Description (last modified by danielk)

On some channels the Payload Start comes after the recording starts which gives the following log:

[please attach logs to ticket after you create the ticket -- dtk].

Attachments (1)

mythbackend.log.gz (40.0 KB) - added by anonymous 18 years ago.
backend log - sorry, didn't get frontend..

Download all attachments as: .zip

Change History (16)

comment:1 Changed 18 years ago by danielk

Description: modified (diff)
Milestone: 0.190.20
Priority: majorminor
Resolution: invalid
Status: newclosed

The log is incomplete. Please attach a backend log with '-v record,siparser,channel' and frontend log with '-v playback' and explain when this happens and when it does not.

comment:2 Changed 18 years ago by kyle@…

I have seen this error too - it happens when the Preferred MPEG2 decoder is set to libmpeg2. It is fine on my system when I switch it back to Standard.

comment:3 Changed 18 years ago by anonymous

Please keep this open for a couple days.. the problem doesn't happen often so it's a bit tough to track it down. I worked around it by increasing the retry count on RingBuffer? open from 6 to 30 so now on effected channels payload start happens around 10 retries.

BTW, this is on CA channels and I believe the fault of payload start coming late is the CAM acting slowly.

comment:4 Changed 18 years ago by kyle@…

Oops - it seems it's got nothing to do with libmpeg2. Still happening on my system.

Changed 18 years ago by anonymous

Attachment: mythbackend.log.gz added

backend log - sorry, didn't get frontend..

comment:5 Changed 18 years ago by anonymous

Resolution: invalid
Status: closedreopened

Forgot to reopen ticket. Please let me know if this isn't enough information. I had to put in a hack to increase file open retries from 6 to 20 in order to get a payload start before the ringbuffer times out.

comment:6 Changed 18 years ago by anonymous

Did some more research.. seems the problems doesn't lie in creating a RingBuffer? in write mode but rather in read mode. It's using the default retryCount of 6 which for me fails on many channels. Optimally it would be nice if DummyDtvRecorder? stayed active right up to Payload Start to ensure the RingBuffer? reader has data.

comment:7 Changed 18 years ago by danielk

It is probably the wait for the PAT & PMT in the siparser causing the problem. I plan on using the ones from the signal monitor in 0.20, but some invasive changes are needed to the siparser. I'll see if I can't put in some compile time enabled hack for an extended wait in the ringbuffer or sending extra dummy data for 0.19...

comment:8 Changed 18 years ago by anonymous

Sending dummy frames would be ideal. That would make tuning near 100% for me. Without the dummy frames the frontend gets very sluggish due to ringbuffer timeouts which makes changing the channel near impossible sometimes.

comment:9 Changed 18 years ago by anonymous

Can you point me to where RingBuffer::OpenFile?() gets called in this case? It defaults to 6 but if I change the default to something 30 it effects many other things (and becomes a major annoyance). I'm just looking for a quick hack for myself.

comment:10 Changed 18 years ago by amadare _@…

I was having this same problem myself. multiple RingBuf?(*.mpg) Error: Invalid file descriptor in 'safe_read()'

believe it to be a permission problem in my case. backend starts are root, frontend as non-root and the mpgs were getting written by backend with no read permission for non root. did a chmod +s on the /video/record directory and all is well in the world.

comment:11 Changed 18 years ago by anonymous

After looking into this further I'm wondering is this is more a thread starting late issue than anything else.

In tv_rec.cpp ~3731: pthread_create(&recorder_thread, NULL, TVRec::RecorderThread?, recorder);

If this new thread takes a few seconds to start things look like they could get out of sync. It looks to me like ringbuffer reads are dependant on TVRec::IsReallyRecording?() which looks to TVRec::IsRecording?() which reads an internal flag which from what I can see is in no way dependant on the recorder thread being started. Am I wrong?

comment:12 Changed 18 years ago by danielk

anon, IsReallyRecording?() is pretty much meaningless with the new LiveTV code. Try the latest SVN though, I committed a couple of ringbuffer switching fixes this morning which may have fixed your problem.

comment:13 Changed 18 years ago by danielk

Summary: DVB - Recording starts before Payload StartDVBRec can take a while to start, keep DummyRec on
Type: defecttask

comment:14 Changed 18 years ago by danielk

(In [8805]) References #894.

In some cases the DVBRecorder takes much longer to start up than it should (especially when 'wait_for_seq_start' is enabled, which is the default). This increases the RingBuffer? retry counts until this can be properly fixed. I'm referencing #894, so I'll know to revert this once this ticket is fixed.

BTW this appears to happen when the PATs and/or PMTs are far apart, when a DVB-S rotor is involved in the tuning, when there are no GOP headers and the Sequence headers are far apart, or when the reception is very poor. Those factors are additive so the current timeouts are usually fine when one or two of these problems exist, but not if three or more exist. This is why people have been reporting tuning problems with particular channels, such as "Sky Travel".

comment:15 Changed 18 years ago by danielk

Resolution: fixed
Status: reopenedclosed

No longer applicable since after Isaac got rid of the DummyDTVRecorder...

Note: See TracTickets for help on using tickets.