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 )
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)
Change History (16)
comment:1 Changed 18 years ago by
Description: | modified (diff) |
---|---|
Milestone: | 0.19 → 0.20 |
Priority: | major → minor |
Resolution: | → invalid |
Status: | new → closed |
comment:2 Changed 18 years ago by
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
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
Oops - it seems it's got nothing to do with libmpeg2. Still happening on my system.
Changed 18 years ago by
Attachment: | mythbackend.log.gz added |
---|
backend log - sorry, didn't get frontend..
comment:5 Changed 18 years ago by
Resolution: | invalid |
---|---|
Status: | closed → reopened |
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
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
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
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
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
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
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
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
Summary: | DVB - Recording starts before Payload Start → DVBRec can take a while to start, keep DummyRec on |
---|---|
Type: | defect → task |
comment:14 Changed 18 years ago by
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
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
No longer applicable since after Isaac got rid of the DummyDTVRecorder...
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.