Opened 14 years ago
Closed 13 years ago
#8507 closed defect (Works for me)
Channel scanning broken - HDHR DVB
Reported by: | Nigel | Owned by: | Nigel |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | MythTV - HDHomeRun | Version: | Master Head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description (last modified by )
Change History (15)
comment:6 Changed 14 years ago by
Status: | assigned → accepted |
---|
Have tested on both OS X and Linux - same result. Problem was 20100121 library synch, but recent trunk (25254) does not exhibit the fault on OS X. I tried examining the differences between defective synch and current 20100519beta1, but could not work out what caused the change.
Interestingly, Linux with the updated lib did not find anything in a scan. I will have to dig further :-(
comment:7 Changed 14 years ago by
Component: | MythTV - Channel Scanner → MythTV - HDHomeRun |
---|
Changing component to HDHomeRun since Silicon Dust are monitoring it.
comment:8 Changed 14 years ago by
Just tested 26257 on OS X. Still broken, but patching in libmythhdhomerun 23467 gives working scan.
comment:9 Changed 14 years ago by
nigel - are you using a wireless network between the HDHomeRun and mythbackend by any chance?
If streaming unfiltered over wireless you will saturate the wireless link, thus delaying or preventing control communication. The newer version of libhdhomerun enforces the communication timeout of 2 seconds. The older version of the library requested a 2 second timeout but we found many operating systems ignored this.
If this is the problem we will need to tweak the way mythtv applies the filter during channel scan - let me know and I will set up a test.
Nick
comment:10 Changed 14 years ago by
Status: | accepted → infoneeded |
---|
comment:11 Changed 14 years ago by
Problem is manifest over wires or wireless nets, different switches, et c. Changing the timeout defaults in your code has no effect.
My primitive testing with hdhomerun_config reveals no filters are set, yet nothing is received. As far as I understand our scanning code, a PID filter is not set until ChannelScanSM::HandlePAT() receives a PAT from the device.
comment:12 Changed 14 years ago by
And just to annoy me further, retested at home with trunk and tcpdump, and it scanned OK. Now rolling back & rebuilding to bracket possibly related changes.
comment:13 Changed 14 years ago by
Scanned OK under MacOS X (both wired and wirelessly). On a Linux machine with a variety of revisions (25525, 23267, 26400ish), it failed to find anything - either wired or wireless. I'm wondering if an OS update on my Mac changed the socket behaviour, but either way, tracing this is becoming very difficult.
comment:14 Changed 13 years ago by
Status: | infoneeded → assigned |
---|
comment:15 Changed 13 years ago by
Status: | assigned → infoneeded |
---|
Nigel,
Can you test this with master? I am able to scan correctly in all permutations of configurations with the HDHR DVB-T model simulator.
comment:16 Changed 13 years ago by
Resolution: | → Works for me |
---|---|
Status: | infoneeded → closed |
No response, works with simulator.
Revs 23011, 2305, 23099 and 23190 all worked.