mm1352000 I sent you an email on Feb 12. Apparently it never got there. I just resent it, let me know if you don't receive it.
HDHomeRun Prime Tuner Locked (1 Viewer)
- Thread starter ChairmanMao
- Start date
- September 1, 2008
- 21,577
- 8,224
- Home Country
-
New Zealand
Hello folks
Just a quick note to say I received Jason's email and I haven't forgotten about this thread. I'm struggling to keep all the balls in the air with no internet access at home.
A comment on the thread topic...
From what Jason said in his email I'm currently thinking there is a fairly serious and low-level issue with the library (live555) that MP's IPTV filter uses for RTSP. In simple terms that means I don't think there will be a quick fix.
What are the options?
Second option is potentially the best option for now. georgius has been working on a new IPTV filter to extend the capabilities and fix some of the bugs and limitations of the current filter:
https://forum.team-mediaportal.com/...ortal-url-source-splitter-iptv-filter.121165/
The new filter is a drop in replacement with a completely different RTSP library. You can download and try it today. Caveat: I don't think anybody has tried it with a CableCARD tuner. It may work beautifully; it may not work at all. Definitely worth a try if you have some time on your hands.
The final option is a possibility in theory too. The issue with it is that TVE 3 is in code freeze and I would prefer to focus on TVE 3.5. For those of you that don't know, TVE 3.5 is the next generation TV Server replacement which is being developed for both MP1 and MP2 (and any other front end that wants to use it). Within the last month I've pretty much finished porting CableCARD tuner support across so expect to see it in the feature list for an upcoming MP2 Native TV build. Anyhow, after reading the email from Jason I promptly decided to code our own simple CableCARD RTSP support into TVE 3.5. To be clear: that code has been written already, it just isn't available for MP1/TV Server today. The third option would be to back port that code to TVE 3.
Another option which I didn't mention is to disable your firewall. I didn't mention this because I know it is not ideal and I wouldn't want to be seen to recommend it... but it is a choice.
So, that is where things stand.
Please feel free to chime in if you have any comments or questions.
Personally I'd be really keen to know if the second option is viable. That filter is probably going to be merged in the foreseeable future, so would be good to know if it doesn't work before the fact.
mm
PS: tag to @FreakyJ and @georgius
Just a quick note to say I received Jason's email and I haven't forgotten about this thread. I'm struggling to keep all the balls in the air with no internet access at home.
A comment on the thread topic...
From what Jason said in his email I'm currently thinking there is a fairly serious and low-level issue with the library (live555) that MP's IPTV filter uses for RTSP. In simple terms that means I don't think there will be a quick fix.
What are the options?
- Upgrade the library and hope it fixes the problem.
- Try the new IPTV filter which uses a different RTSP library.
- Code our own CableCARD RTSP support.
Second option is potentially the best option for now. georgius has been working on a new IPTV filter to extend the capabilities and fix some of the bugs and limitations of the current filter:
https://forum.team-mediaportal.com/...ortal-url-source-splitter-iptv-filter.121165/
The new filter is a drop in replacement with a completely different RTSP library. You can download and try it today. Caveat: I don't think anybody has tried it with a CableCARD tuner. It may work beautifully; it may not work at all. Definitely worth a try if you have some time on your hands.
The final option is a possibility in theory too. The issue with it is that TVE 3 is in code freeze and I would prefer to focus on TVE 3.5. For those of you that don't know, TVE 3.5 is the next generation TV Server replacement which is being developed for both MP1 and MP2 (and any other front end that wants to use it). Within the last month I've pretty much finished porting CableCARD tuner support across so expect to see it in the feature list for an upcoming MP2 Native TV build. Anyhow, after reading the email from Jason I promptly decided to code our own simple CableCARD RTSP support into TVE 3.5. To be clear: that code has been written already, it just isn't available for MP1/TV Server today. The third option would be to back port that code to TVE 3.
Another option which I didn't mention is to disable your firewall. I didn't mention this because I know it is not ideal and I wouldn't want to be seen to recommend it... but it is a choice.
So, that is where things stand.
Please feel free to chime in if you have any comments or questions.
Personally I'd be really keen to know if the second option is viable. That filter is probably going to be merged in the foreseeable future, so would be good to know if it doesn't work before the fact.
mm
PS: tag to @FreakyJ and @georgius
Hi mm,
I carefully read Wireshark log from post #26 and it seems that remote server (HDHomeRun device?) not correctly handles RTSP TEARDOWN request. By Wireshark log (packet 15989, TEARDOWN request) is sent TEARDOWN request to remote server. Remote server can response with sender report goodbye packet, but must response with correct RTSP response (like response on OPTIONS, DESCRIBE, SETUP and PLAY requests). As I can see, the server didn't send any response (except TCP reset which means that connection was reset (e.g. closed socket on remote server)). Also remote server didn't accept any receiver report packets (from client port 50737 to server port 5005) - all returned with ICMP destination unreachable (e.g. packets 948, 949; 1749, 1751; ...; 16000, 16001). It seems that remote server closes main RTSP connection (on port 554) and never opens control channel port (server port 5005). But data channel port is not closed and data are transmitted.So, from my point of view, server has at least bad RTSP protocol implementation.
I carefully read Wireshark log from post #26 and it seems that remote server (HDHomeRun device?) not correctly handles RTSP TEARDOWN request. By Wireshark log (packet 15989, TEARDOWN request) is sent TEARDOWN request to remote server. Remote server can response with sender report goodbye packet, but must response with correct RTSP response (like response on OPTIONS, DESCRIBE, SETUP and PLAY requests). As I can see, the server didn't send any response (except TCP reset which means that connection was reset (e.g. closed socket on remote server)). Also remote server didn't accept any receiver report packets (from client port 50737 to server port 5005) - all returned with ICMP destination unreachable (e.g. packets 948, 949; 1749, 1751; ...; 16000, 16001). It seems that remote server closes main RTSP connection (on port 554) and never opens control channel port (server port 5005). But data channel port is not closed and data are transmitted.So, from my point of view, server has at least bad RTSP protocol implementation.
- September 1, 2008
- 21,577
- 8,224
- Home Country
-
New Zealand
Hello georgius
The server doesn't support RTCP. AFAIK this is true for all CableCARD tuners.
What Jason said was that the server closed the connection - sent a TCP FIN in packet 4563 which was acknowledged at packet 4564. So, live555 was sending the TEARDOWN on a closed connection. The reset means that the client should open a new connection... but it doesn't do that. The way I read the live555 RTSPClient.cpp code it seems that live555 uses a single connection for communication with the server. It doesn't actually handle the closed connection/socket. There is a function to close the current connection (resetTCPSockets()). If this were called, it would trigger a new connection to be opened to send the next message. Normally that function is only called in error conditions and in the destructor.
So, this is why I think we are at fault. We should detect that the server has closed the connection and open a new connection.
Do you think your new filter would handle this scenario properly?
mm
The server doesn't support RTCP. AFAIK this is true for all CableCARD tuners.
What Jason said was that the server closed the connection - sent a TCP FIN in packet 4563 which was acknowledged at packet 4564. So, live555 was sending the TEARDOWN on a closed connection. The reset means that the client should open a new connection... but it doesn't do that. The way I read the live555 RTSPClient.cpp code it seems that live555 uses a single connection for communication with the server. It doesn't actually handle the closed connection/socket. There is a function to close the current connection (resetTCPSockets()). If this were called, it would trigger a new connection to be opened to send the next message. Normally that function is only called in error conditions and in the destructor.
So, this is why I think we are at fault. We should detect that the server has closed the connection and open a new connection.
Do you think your new filter would handle this scenario properly?
mm
It seems that I missed closing connection. As I check the filter (merged) code, it doesn't open new connection, so I add this to my TO DO list.
- December 24, 2013
- 31
- 6
- 30
- Home Country
-
United States of America
Well since the first option is out of question and the third option probably won't come to fruition for a while, I decided to give the second option a go. Unfortunately, that did not go well at all. The filter seems to throw errors which I cannot understand at all. I've posted the logs incase you wanted to take a look. Thanks for the update. Worst case scenario is I may have to wait for the release of TVE 3.5.
- September 1, 2008
- 21,577
- 8,224
- Home Country
-
New Zealand
Thanks for trying. I agree that doesn't look so good at all:
No output pin means no streaming.
@georgius: is the output pin created dynamically? That probably is not going to work for TV Server if that is the case. Graph building is attempted before URL is supplied to filter. I note that TsWriter will accept connection with any media types. Maybe it helps?
No output pin means no streaming.
@georgius: is the output pin created dynamically? That probably is not going to work for TV Server if that is the case. Graph building is attempted before URL is supplied to filter. I note that TsWriter will accept connection with any media types. Maybe it helps?
- December 24, 2013
- 31
- 6
- 30
- Home Country
-
United States of America
Yup got it right here. It should be attached.Second take: I spotted this too...
Are you able to check if that file exists and post it if it does?
Thanks in advance.
Yes, output pin(s) is created dynamically, but you can call Load() method with URL "udp://@0.0.0.0:1234" (as in TvCardDVBIPBuiltin.cs) to create MPEG2-TS output pin.
Unfortunatelly, this dmp file is useless at this time, because I don't have dbg files from that build.Yup got it right here. It should be attached.Second take: I spotted this too...
Are you able to check if that file exists and post it if it does?
Thanks in advance.