Opened 14 years ago

Closed 14 years ago

#1619 closed patch (duplicate)

DVB: backend won't tune after the first channel tune

Reported by: Mark.Buechler@… Owned by: danielk
Priority: minor Milestone: 0.20
Component: dvb Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Mythbackend tunes first DVB channel fine, after entering LiveTV. Changing channels after that never gets a PAT it seems. Mythbackend Log attached.

Attachments (3)

log.txt (37.7 KB) - added by Mark.Buechler@… 14 years ago.
backend log
foundProgram.diff (2.5 KB) - added by Mark.Buechler@… 14 years ago.
A patch which fixes the issue for me. Not sure if this is the "correct" way of doing this though.
check-tsid.diff (1.7 KB) - added by Stuart Auchterlonie 14 years ago.
Check the tsid of PATs

Download all attachments as: .zip

Change History (11)

Changed 14 years ago by Mark.Buechler@…

Attachment: log.txt added

backend log

comment:1 Changed 14 years ago by Anonymous

Component: mythtvdvb
Owner: changed from Isaac Richards to danielk

I am seeing the same issue here. If I change to a channel on a different switch port, it works ok, but if I switch to a channel on the same sat, it never actually tries to retune.

comment:2 Changed 14 years ago by anonymous

one thing I noticed in both Mark's log is that 'signal lock' is not happening the second time around. The same thing happens to me despite being able to tne these channels if I switch sources in-between tunes.

comment:3 Changed 14 years ago by Mark.Buechler@…

Resolution: fixed
Status: newclosed

Seems to have been fixed by some later SVN. No longer an issue.

comment:4 Changed 14 years ago by Mark.Buechler@…

Resolution: fixed
Status: closedreopened

Looks like this still is a problem but takes more than a single channel change to reveal it this time. It can happen seemingly randomly.

comment:5 Changed 14 years ago by Mark.Buechler@…

Looks like forcing cacheTables to false fixes this issue for me. It seems for some reason on my setup an empty/invalid PAT is getting cached and Myth never attempts to look for a new one, from best I can tell anyway.

comment:6 Changed 14 years ago by Mark.Buechler@…

Seems the problem here is the PAT version number and when a new PAT comes very late. Firstly, the PAT version seems ALWAYS to be 0. That causes HandleTSTables() to return before HandleTables?() is called since IsRedundant?() returns > 0. Since ProcessPAT comes after HandleTables?, the new PAT is never processed because the version == 0 on the old and the new PAT.

Also, IsReduntant?() is called from HandleTables? as well which forces it to return true before it has a chance to call ProcessPAT.

So, the problem is if the newest PAT isn't seen on the very first ProcessPAT it will never get seen due to its version being the same (0) as the old. I fixed it temporarily by making global foundProgram and putting that in IsRedundant?() forcing it to return false of foundprogram is false and table_id == PAT.

Not sure the proper way of fixing this though.

Changed 14 years ago by Mark.Buechler@…

Attachment: foundProgram.diff added

A patch which fixes the issue for me. Not sure if this is the "correct" way of doing this though.

comment:7 Changed 14 years ago by anonymous

Type: defectpatch

comment:8 Changed 14 years ago by danielk

Resolution: duplicate
Status: reopenedclosed

It looks like you are getting a PAT from a different multiplex. So this looks like a duplicate of #1049... which I'm actually surprised that no DVB-Land person has looked at implementing, considering the number of duplicate tickets which have been opened.

The zero version number for the PAT is probably just a coincidence. This is only incremented when the PAT changes so you will see many with the same version number in a row and the small counter wraps around fairly often to zero.

Changed 14 years ago by Stuart Auchterlonie

Attachment: check-tsid.diff added

Check the tsid of PATs

Note: See TracTickets for help on using tickets.