MP 1.6 and HDHomerun Prime - not releasing / deactivating tuners when done. (2 Viewers)

mm1352000

Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    So do this apply to me as well?
    Yes, if you're still having problems with tuners not being released.

    I looked at the inbound rules and and it appeared that ICMP was allowed.
    The inbound rules for ICMP are not relevant. It is the outbound rules that are critical. The PC is sending an ICMP packet to the PRIME.

    I should again note that when I say release that it is different then when HDHR QuickTV releases a tuner (LED goes out immediately). When MP releases a tuner the tuner LED blinks for some time before going out (I guess indicating that MP still has it reserved but not active). I still wonder if that is by design.
    No it is not by design, and I can't explain this. I do know that HDHR QuickTV (like N-PVR) uses libhdhomerun to interact with the tuners. I have no idea what differences that could give rise to. The only thing I can do is ask Silicondust to confirm the technical requirements for releasing a tuner.

    Also, the intermittent excessively long channel change issue that I collected data on still remains...
    Understood. I'm sorry I'm still operating without access to internet at home.
     

    T^2

    Portal Pro
    December 9, 2013
    133
    10
    57
    Home Country
    United States of America United States of America
    So do this apply to me as well?
    Yes, if you're still having problems with tuners not being released.

    I looked at the inbound rules and and it appeared that ICMP was allowed.
    The inbound rules for ICMP are not relevant. It is the outbound rules that are critical. The PC is sending an ICMP packet to the PRIME.

    I should again note that when I say release that it is different then when HDHR QuickTV releases a tuner (LED goes out immediately). When MP releases a tuner the tuner LED blinks for some time before going out (I guess indicating that MP still has it reserved but not active). I still wonder if that is by design.
    No it is not by design, and I can't explain this. I do know that HDHR QuickTV (like N-PVR) uses libhdhomerun to interact with the tuners. I have no idea what differences that could give rise to. The only thing I can do is ask Silicondust to confirm the technical requirements for releasing a tuner.

    Also, the intermittent excessively long channel change issue that I collected data on still remains...
    Understood. I'm sorry I'm still operating without access to internet at home.

    No reason for an apology. I understand your circumstance... and I'm in no hurry. I posted my last just for the record.

    For the most part the MP and HDHR combination is working quite nicely and the "Boss" and I are enjoying it. I've only spoken to her a couple of times about it and the gist I get is that she's acclimatizing to MP with out much trouble. So all in all I may be reversing the trend somewhat on the previously downward spiral of the WAF. However, knowing what tough customers they can be - when it comes to WAF - I have an interest in making the setup as robust/reliable/transparent as possible. Not to mention - as I mentioned before - I like to find solutions to problems. Perhaps in the end you'll find something and it will end up as a net positive for MP and MP users who have HDHR primes.

    I'll keep checking in from time to time to see what you may have found...[DOUBLEPOST=1391722957][/DOUBLEPOST]
    So do this apply to me as well?
    Yes, if you're still having problems with tuners not being released.

    No, not having problems getting tuners to release as long as Stealth Blocked Ports in Norton is disabled.

    I looked at the inbound rules and and it appeared that ICMP was allowed.
    The inbound rules for ICMP are not relevant. It is the outbound rules that are critical. The PC is sending an ICMP packet to the PRIME.

    Sorry... It wasn't clear to me which direction was being talked about in the previous traffic. I assumed that communication was happening from MP to the Prime because at least the channel changes and tuner releases were occurring. I also assumed that perhaps the Prime was sending some feedback to MP (after receiving a release request) and that this communicating was failing due to the firewall. Meh... What can I say... Stupid Layman.... :)
     
    Last edited:

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    @A Happy Cloud

    To follow up on the log files provided in your earlier post...
    https://forum.team-mediaportal.com/...g-tuners-when-done.124174/page-3#post-1060399

    You're using ARGUS.

    When you use ARGUS with TV Server, ARGUS is responsible for deciding how and when to use tuners (scheduling) and TV Server does the "grunt work" (tuner control). To be clear, TV Server won't lock or unlock a tuner unless ARGUS tells it to.

    It appears that ARGUS tuned LMN HD on TV Server tuner 3 (PRIME tuner 0) to record "I Survived (Susan, John & Jean, Penny - 45)".
    It also tuned LMN HD on TV Server tuner 4 (PRIME tuner 2) to record "I Survived\I Survived (Cults - 58)".

    At the end of the log files ARGUS had not told TV Server to stop recording with tuner 3 or 4... so as far as both ARGUS, TV Server, and HDHR config are concerned, both tuner 3/0 and 4/2 are understood to be busy. In other words, I think TV Server configuration was not showing you the full picture. I don't know why but I suspect it is some kind of integration issue with ARGUS and TV Server.

    Next time you see something like this I suggest you check the tuner status in ARGUS as well to confirm whether it thinks the tuner is busy.

    mm
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    @T^2
    Looking at your log files and captures for the long tuning issue...
    It looks like TV Server is at fault though right now I can't tell exactly what the problem is.

    The Wireshark trace for capture 3 clearly shows that the tuner is streaming and delivers PMT once every 100 ms or so. As such, it should definitely not be taking 20+ seconds for TV Server to get PMT. I do find it odd that the IPTV source log file is complaining about discontinuity errors on PID 0 right up to the point of the channel change:
    31-01-2014 10:45:52.818 [ 4bc] [{4D6BFD2D-741F-4E13-8A3E-1684AD041698}] [Warning] MPIPTVSourceStream: FillBuffer(): discontinuity detected, PID: 0, expected counter: 1, packet counter: 0
    [2014-01-31 10:45:52,823] [Log ] [9 ] [DEBUG] - DRI CC: tuning...

    ...and then it suddenly goes quiet. I'm wondering if the IPTV filter stops delivering the stream for some reason. Unfortunately I can't tell as the data level debug setting didn't seem to take hold.

    The other thing I'm wondering about is the similarity of the PMT from the previous channel. A couple of years ago we had a problem where TV Server failed to pick up PMT on changes between certain channels due to the similarity of the PMT. As far as I know that problem is completely solved and I don't think it is happening here, but you never know.

    mm
     

    T^2

    Portal Pro
    December 9, 2013
    133
    10
    57
    Home Country
    United States of America United States of America
    @T^2
    Looking at your log files and captures for the long tuning issue...
    It looks like TV Server is at fault though right now I can't tell exactly what the problem is.

    The Wireshark trace for capture 3 clearly shows that the tuner is streaming and delivers PMT once every 100 ms or so. As such, it should definitely not be taking 20+ seconds for TV Server to get PMT. I do find it odd that the IPTV source log file is complaining about discontinuity errors on PID 0 right up to the point of the channel change:
    31-01-2014 10:45:52.818 [ 4bc] [{4D6BFD2D-741F-4E13-8A3E-1684AD041698}] [Warning] MPIPTVSourceStream: FillBuffer(): discontinuity detected, PID: 0, expected counter: 1, packet counter: 0
    [2014-01-31 10:45:52,823] [Log ] [9 ] [DEBUG] - DRI CC: tuning...

    ...and then it suddenly goes quiet. I'm wondering if the IPTV filter stops delivering the stream for some reason. Unfortunately I can't tell as the data level debug setting didn't seem to take hold.

    The other thing I'm wondering about is the similarity of the PMT from the previous channel. A couple of years ago we had a problem where TV Server failed to pick up PMT on changes between certain channels due to the similarity of the PMT. As far as I know that problem is completely solved and I don't think it is happening here, but you never know.

    mm

    OK... standing by... If you need me to do any more data captures let me know...
     

    bobdro

    Portal Member
    February 8, 2014
    7
    0
    Home Country
    United States of America United States of America
    Just to add my two cents...... I am having the exact problem also, so you are not alone! Tuners fail to release and sometimes can't seize them. Firewall off, everything works. Tried every setting is the posts to no avail. Waiting to see what is found. Thank you.
     

    bobdro

    Portal Member
    February 8, 2014
    7
    0
    Home Country
    United States of America United States of America
    tried wireshark, because of tuner slow and locking up file is almost 300mb. Too large to attach,
     

    Users who are viewing this thread

    Top Bottom