Opened 17 years ago
Closed 17 years ago
#1619 closed patch (duplicate)
DVB: backend won't tune after the first channel tune
| Reported by: | 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)
Change History (11)
comment:1 Changed 17 years ago by
| Component: | mythtv → dvb |
|---|---|
| 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 17 years ago by
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 17 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Seems to have been fixed by some later SVN. No longer an issue.
comment:4 Changed 17 years ago by
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
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 17 years ago by
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 17 years ago by
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 17 years ago by
| 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 17 years ago by
| Type: | defect → patch |
|---|
comment:8 Changed 17 years ago by
| Resolution: | → duplicate |
|---|---|
| Status: | reopened → closed |
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.
backend log