Reply to thread

Message: <blockquote data-quote="mm1352000" data-source="post: 1062241" data-attributes="member: 82144">Thanks <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" />So just looking through everything now...Looks like you attempted 24 tune requests (AKA channel changes) over roughly 15 minutes. Of those 24, the Wireshark trace only shows me the last one in full. Based on my analysis, I think I'd be correct to assume that the tuner is left locked after that last attempt to view WCBS (channel 2).If you are familiar with Wireshark, you can see exactly what I'm looking at by opening the snippet you uploaded, adding ",4444,50560-50585" to the HTTP TCP ports list in preferences (edit > preferences... > protocols > HTTP > TCP ports), and applying the filter "(ip.dst == 192.168.1.163 or ip.src == 192.168.1.163) and (http or rtsp or rtcp or icmp)". To follow along easily, you might also want to configure your columns (right click on column headers > column preferences...) to show the number, time (and/or absolute time and date), source address, destination address, protocol, source port, destination port and information fields.At time 2.92 (Wireshark reference time - time 0 - is when the capture started, approximately 20:52:30 your time) packet 74 I see the first request to AVTransport GetTransportInfo() which is to check if any other process might be using the tuner. We get the result back and see that the CurrentTransportState is STOPPED. Okay - so nobody else is actively using the tuner and we are good to go ahead and tune. Tuning is the CAS SetChannel() and AVTransport Play() + RTSP OPTIONS, DESCRIBE, SETUP and PLAY requests. At time ~3.06 the tuner is streaming channel 2. Excellent.After this you see Tuner GetTunerParameters() requests every second or so. Presumably this is because you're following things in the manual control section of TV Server configuration. These requests are TV Server grabbing the tuner signal strength and quality details. The other thing to note is the RTCP receiver report and ICMP destination unreachable responses bouncing back to 192.168.1.217 (the server) every few seconds. These are normal RTCP requests that TV Server is sending to the PRIME. Obviously the PRIME doesn't support RTCP. No problem - these can be ignored.At 13.90 packet 4803 we see an AVTransport Stop() request come through as TV Server is asked to release the tuner. That request is acknowledged with an HTTP 200 OK response. Immediately following that at 13.93, we see RTSP TEARDOWN (packet 4819) and RTCP goodbye (packet 4832) requests go out. We also see an ICMP destination unreachable packet (4833) bounce back to TV Server. That corresponds with the RTCP goodbye.At this point from TV Server's perspective the tuner should have stopped streaming and unlocked... but it looks like it hasn't. We can see this by modifying the filter to be "(ip.dst == 192.168.1.163 or ip.src == 192.168.1.163) and (http or rtsp or rtcp or rtp or icmp)". RTP is the streamed video and audio data.Finally, at 27.62 we see a final ICMP destination unreachable packet (10406) bounced to the PRIME, presumably at the point where you take down the firewall. Streaming stops.Executive summary: TV Server definitely attempts to stop and unlock the tuner, and as part of that process it definitely sends an RTSP TEARDOWN. In other words, I think tuner 3 (PRIME tuner 1319F623-0) should be unlocked.Obviously we're interested to know why the PRIME is not unlocked. What can we see?Well, when I apply the filter "(!rtp or icmp) and ip.addr == 192.168.1.163" I see all non-streaming traffic between the server PC and the PRIME.I see a bunch of TCP packets exchanged between ports 49588 and 65001 every second or so. As far as I can tell this is HDHR Config using libhdhomerun to monitor the tuner status. Presumably this is not keeping the tuner locked... though I guess you never know.To ignore the HDHR Config packets I apply the filter "(!rtp or icmp) and (!tcp or (tcp.dstport != 49588 and tcp.dstport != 65001)) and (ip.dst == 192.168.1.163 or ip.src == 192.168.1.163)".I don't see anything obviously interesting here aside from packet 10578... which I can't explain.Of note is that packets 4820 and 4837 appear to show that the PRIME acknowledges the RTSP TEARDOWN.Also, the RTSP TEARDOWN session ID (38300) corresponds with the session ID returned in the RTSP SETUP response (packet 38300).In short, I have no idea why the PRIME doesn't stop streaming unless the information I have about tuner locking and unlocking is incorrect.I've asked Jason from Silicondust to assist me to figure out what is going on. In the meantime, thank you for your patience and the information. Please sit tight while we investigate further...mm</blockquote>

Verification