Opened 12 years ago

Closed 12 years ago

#4723 closed defect (invalid)

Tuner Timeouts not being honored by frontend.

Reported by: eric.bosch@… Owned by: jwestfall
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

I have a 6200 Cable box attached via firewire, and am having very unreliable channel locking. I have set the signal timeout to 20 seconds and the tuner timeout to 30 seconds. I am using sure-change.sh as my channel changing script with arguments t=6, mode=B so it can try up to 6 times. Often, before all the iterations are done, the frontend drops back to the menu with a video error, while sure-change.sh actually completes successfully just after frontend drops out. Additionally, there appears to be an error on preview processor, it's saying the file is not local, however it actually is. I will attach some excertps from the backend log.

2008-02-19 23:51:13.389 Preview Error: Previewer file '/video/recordings/LiveTV/1233_20080219235111.mpg' is not valid. 2008-02-19 23:51:13.391 Preview Error: Run() file not local: '/video/recordings/LiveTV/1233_20080219235111.mpg' 2008-02-19 23:51:13.396 Preview Error: Preview process not ok.

Attachments (1)

backend-channel-change.txt (5.3 KB) - added by eric.bosch@… 12 years ago.
Excerpts of backend log while tuning on live tv with firewire tuner on 6200

Download all attachments as: .zip

Change History (9)

Changed 12 years ago by eric.bosch@…

Attachment: backend-channel-change.txt added

Excerpts of backend log while tuning on live tv with firewire tuner on 6200

comment:1 Changed 12 years ago by eric.bosch@…

Actually, I just looked for the file it says is not local, and it appears to have gotten the wrong filename. The actual file is 1233_20080219235112.mpg.

comment:2 Changed 12 years ago by eric.bosch@…

Would it be possible to integrate something like sure-change.sh into myth, so that a per-channel selection of the mode can be selected? For some of my channels, I can only get p2p connections to work, while others must be Broadcast.

comment:3 Changed 12 years ago by danielk

Milestone: 0.21unknown
Owner: changed from Isaac Richards to jwestfall
Status: newassigned
Version: 0.21-fixeshead

comment:4 Changed 12 years ago by eric.bosch@…

I'm doing a quick test and modifying the SignalTimeout? and ChannelTimeout? values associated with Firewire devices in videosource.cpp and will get back shortly as to whether this fixes the problem... These values should be getting pulled from the database-stored timeouts rather than being hardcoded.

comment:5 Changed 12 years ago by eric.bosch@…

My attempts to rectify this were not successful after hours of looking through the code. What it boils down to, I believe NuppelVideoPlayer? needs to stop expecting a stream from the backend until after the channel change has completed successfully. From what I could see in the code, NuppelVideoPlayer? simply tries to handle the stream interruption, ignorant of what the backend is doing. Would there be a way to have the player essentially put the playback into a paused state until after the channelchanger completes successfully? Unfortunately, I don't quite understand how all of the pieces fit together. Is there any documentation available that describes at a high level as how the overall system works?

comment:6 Changed 12 years ago by anonymous

Eric, the NuppelVideoPlayer? is told to go into a wait for signal before reading more data state by adding a dummy recording to the livetvchain. This is what is done when the signal monitor is active for the hdhomerun and dvb signal monitors. This should also be done by the firewire recorder's signal monitor. Once we switch from the signal monitor to the recorder we always expect data to be fed without interruption. The proper way for a recorder to handle temporary signal interruptions would be to generate a dummy a/v stream with the same properties as the last seen video stream. (replay last full keyframe set maybe?)

comment:7 Changed 12 years ago by eric.bosch@…

Ah, I see. Then, I believe that what may be happening could be an issue with the channel changer script basically hanging the backend up while it waits for completion, so perhaps a rewrite of the script would be in order, or to implement a threaded call to that script. Not sure if thats what's happening.. I've been looking at the code for some time, but this is obviously a bit on the complex side in that area. What I see happen, sometimes (on long-duration tuning attempts) is the frontend drops back to the menu, and if I try to go back into livetv, the frontend eventually comes back saying the backend has gone away, but when the channel changer finally does exit, things go back to normal.

comment:8 Changed 12 years ago by danielk

Resolution: invalid
Status: assignedclosed

Eric, that sounds right. I have a Dish channel change script that I run backgrounded because it takes too long (I have it perform a long procedure that both makes sure the STB is awake and also is not 'stuck' on a bogus channel.)

There is no facility in MythTV to allow it wait for a channel change script like it does for long internal channel change functions so long running scripts must be backgrounded.

I'm marking this as invalid, a "feature request without patch". But if someone wanted to add that kind of feature to MythTV, I know I would use it.

Note: See TracTickets for help on using tickets.