[TV] - HD-PVR TV freezes After Channel Change When using SPDIF (1 Viewer)

CanadianEh

MP Donator
  • Premium Supporter
  • July 21, 2011
    130
    16
    Home Country
    United States of America United States of America
    Presumably you only experience this problem when playing live TV on remote clients, right?

    Most likely. My TV Server is in the basement, so it's never used for playback.


    If someone can specify which logs would be helpful on both the client and the server, I will capture them and pass them along.
    All log files from both client and server are required.
    ...
    5. Post/attach the two zip files from steps 3 and 4 here.

    Thanks,
    mm

    So, since putting the client and the server in the respective debug modes, the issue hasn't occurred since, of course :) . I expect it will crop up again soon, and will place an update once I've successfully captured the condition.

    Thank you, again, mm, and have a Happy New Year!
     

    CanadianEh

    MP Donator
  • Premium Supporter
  • July 21, 2011
    130
    16
    Home Country
    United States of America United States of America
    Okay, so the freeze issue occurred again tonight at just before 7:20pm EST while watching TBS - The Big Bang Theory. Attaching both the Zip file from the client and from the server. Client was closed out before the watchdog zipped the logs, while the TVServer remained online - I just gathered what was there.

    Thank you, again, mm for your time and expertise :)
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Hello and happy new year [well, it is January 1 here in NZ!] :)

    I'll get straight to the point:
    [2013-12-31 19:24:25,840] [2afc4f10] [ 4e4] - FileReader::OpenFile() unbuff, 6 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:25,862] [2afc4f10] [ e38] - FileReader::OpenFile() unbuff, 6 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:25,960] [2afc4f10] [ 4e4] - FileReader::OpenFile() unbuff, 7 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:25,982] [2afc4f10] [ e38] - FileReader::OpenFile() unbuff, 7 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:26,100] [2afc4f10] [ 4e4] - FileReader::OpenFile() unbuff, 8 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:26,122] [2afc4f10] [ e38] - FileReader::OpenFile() unbuff, 8 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:26,260] [2afc4f10] [ 4e4] - FileReader::OpenFile() unbuff, 9 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:26,282] [2afc4f10] [ e38] - FileReader::OpenFile() unbuff, 9 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:26,440] [2afc4f10] [ 4e4] - FileReader::OpenFile() unbuff, 10 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:26,462] [2afc4f10] [ e38] - FileReader::OpenFile() unbuff, 10 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:26,640] [2afc4f10] [ 4e4] - FileReader::OpenFile() unbuff, 11 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:26,662] [2afc4f10] [ e38] - FileReader::OpenFile() unbuff, 11 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:26,860] [2afc4f10] [ 4e4] - FileReader::OpenFile() unbuff, 12 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:26,882] [2afc4f10] [ e38] - FileReader::OpenFile() unbuff, 12 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:27,100] [2afc4f10] [ 4e4] - FileReader::OpenFile() unbuff, 13 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:27,122] [2afc4f10] [ e38] - FileReader::OpenFile() unbuff, 13 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:27,350] [2afc4f10] [ 4e4] - FileReader::OpenFile() unbuff, 14 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:27,372] [2afc4f10] [ e38] - FileReader::OpenFile() unbuff, 14 tries to open \\server7\timeshift\live8-0.ts.tsbuffer3.ts
    [2013-12-31 19:24:27,600] [2afc4f10] [ 4e4] - FileReader::OpenFile(), open file \\server7\timeshift\live8-0.ts.tsbuffer3.ts failed. Error code 2
    [2013-12-31 19:24:27,600] [2afc4f10] [ 4e4] - SEEK FAILED
    [2013-12-31 19:24:27,600] [2afc4f10] [ 4e4] - FileReader::Read() no open file
    [2013-12-31 19:24:27,600] [2afc4f10] [ 4e4] - READ FAILED2
    [2013-12-31 19:24:27,605] [2afc4f10] [ 4e4] - FileReader::CloseFile() no open file

    I think error code 2 means that the file could not be found.

    @Owlsroost is this a familiar SMB access problem?

    mm
     

    CanadianEh

    MP Donator
  • Premium Supporter
  • July 21, 2011
    130
    16
    Home Country
    United States of America United States of America
    I ran into this again last night, and sure enough it was the same error. Does the 'timeshifting' feature and the tsbuffer files get created in a different way when using the standard RTSP client access? I've never had much luck with RTSP, because as soon as I revert back to it, I get artifacts on the screen every couple of minutes - even on a gigabit network with minimal traffic.

    I'm just trying to figure out if I should continue down the road of troubleshooting the UNC streaming, or go back to troubleshooting RTSP.

    Thanks!
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Does the 'timeshifting' feature and the tsbuffer files get created in a different way when using the standard RTSP client access?
    No. The files on the server are the same. The difference is in how they're accessed from the client. With UNC, they're shared directly (ie. the magic of Windows shares based on the SMB protocol should enable TsReader to read the files as if they were local files); with RTSP, the content is streamed to TsReader rather than read directly from the file system.

    I've never had much luck with RTSP, because as soon as I revert back to it, I get artifacts on the screen every couple of minutes - even on a gigabit network with minimal traffic.

    I'm just trying to figure out if I should continue down the road of troubleshooting the UNC streaming, or go back to troubleshooting RTSP.
    Well, I think you'd run into the freezing-after-channel-change issue if you go back to RTSP. That would have to be dealt with in the streaming server.
    The problem with this UNC issue is that we don't seem to have much control over it. I mean, the files should are there. It is just a case of issues with the SMB protocol and/or the MS implementation of it.

    mm
     

    CanadianEh

    MP Donator
  • Premium Supporter
  • July 21, 2011
    130
    16
    Home Country
    United States of America United States of America
    Interesting. I had the same "freeze" last night, so I browsed my timeshifting folder on the server, and noticed that the buffer files were created every 14(?) minutes during an hour-long show, and for whatever reason, it finished the 3rd buffer file, and never started the 4th one up. Is this apparent in any way in the logs I uploaded the other day? I'm wondering if this has nothing to do with the SPDIF issue at all now. If it looks that way to you, let me know, and I can always create a new thread for this issue.

    Thanks!
     

    CanadianEh

    MP Donator
  • Premium Supporter
  • July 21, 2011
    130
    16
    Home Country
    United States of America United States of America
    So, today I attempted to switch back to RTSP from UNC (to try to get away from the buffer file 'freeze' I was having, covered in a different thread), and yes I immediately hit the "freeze after channel change" issue related to the HDPVR/SPDIF configuration.

    Should this be logged as a bug to hopefully be addressed in the future? Unfortunately, in the USA and Canada, the only way to record HD channels that are not OTA is to use a Hauppauge HD-PVR or similar capture device, so as this product becomes more popular in North America, I think we'll see more people running into this issue.

    Thanks!
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Hello again CanadianEh

    Should this be logged as a bug to hopefully be addressed in the future?
    I'm already tracking it in my head... but at this point it seems impossible to resolve properly/nicely. In other words, I can't see it being resolved in the near or foreseeable future.

    Unfortunately, in the USA and Canada, the only way to record HD channels that are not OTA is to use a Hauppauge HD-PVR or similar capture device, so as this product becomes more popular in North America, I think we'll see more people running into this issue.
    That might be true in Canada where you are, but Americans that can use CableCARD tuners typically don't have this problem (except if they want premium content - HBO, Starz etc.).

    mm
     

    CanadianEh

    MP Donator
  • Premium Supporter
  • July 21, 2011
    130
    16
    Home Country
    United States of America United States of America
    Unfortunately, in the USA and Canada, the only way to record HD channels that are not OTA is to use a Hauppauge HD-PVR or similar capture device, so as this product becomes more popular in North America, I think we'll see more people running into this issue.
    That might be true in Canada where you are, but Americans that can use CableCARD tuners typically don't have this problem (except if they want premium content - HBO, Starz etc.).

    mm[/quote]

    Hi mm. Actually I'm in the USA, right near the Canadian border (the screenname is a long story lol). Cablecards are limited to physical cable companies (ie: Comcast, Time Warner, etc), and even still they are a pain, as all content has the potential to be flagged with either copy freely, one time record, or no copy/record. Satellite companies DirecTV and Dish Network are not bound by the same FCC laws, so no 'cable card' alternative exists there. So, from what I've seen, most people tend to go the route of the HD-PVR's, since then they're not locked into one specific provider, and they can record any channel that their cable or satellite STB can record.

    You guys have it much easier with DVB-S :) I really wish that we had that as an option here... oh well, maybe next lifetime :)



    So, random thought on this, though. You said something about a theory of the SPDIF audio taking longer than usual to stream or be detected. Is it possible to increase the timeout on this in any way? I do agree with your theory, as even with streaming over UNC, there is a period of 1-2 seconds where the 'stream' starts initially with video only, followed with sound about 2 seconds later.

    It's probably not nearly as simple as adding a timeout, but I thought I'd throw it out there. Also, if you do come up with any items you'd like tested with this config, please let me know, and I'll switch back to RTSP to test them out for you.
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Actually I'm in the USA, right near the Canadian border (the screenname is a long story lol).
    Ahhh, I just assumed from your screen name. Sorry. :oops:

    Cablecards are limited to physical cable companies (ie: Comcast, Time Warner, etc)...
    Yes and no. Verizon FIOS is not a traditional cable service, and yet my understanding is that they are one of the better providers in terms of DRM/copy-protection. I take your point.

    ...and even still they are a pain, as all content has the potential to be flagged with either copy freely, one time record, or no copy/record.
    Yes, these channels are not "in the clear" (totally unencrypted) like clear QAM, but if you have a CableCARD + CableCARD tuner all copy-freely channels can be recorded and timeshifted to your heart's content as if they were clear QAM. It is only the channels flagged with higher copy protection that can't. For FIOS, that means most channels are effectively in the clear. You understand that, right?

    Satellite companies DirecTV and Dish Network are not bound by the same FCC laws, so no 'cable card' alternative exists there. So, from what I've seen, most people tend to go the route of the HD-PVR's, since then they're not locked into one specific provider, and they can record any channel that their cable or satellite STB can record.
    This is true... but some people get a certain brand of tuner and use a certain plugin to receive and decrypt the channels directly with their PC. That's very similar to what people in other parts of the world do.

    You guys have it much easier with DVB-S :) I really wish that we had that as an option here... oh well, maybe next lifetime :)
    The grass always looks greener... :D
    I can only speak for New Zealand and partially for Australia.

    Most of the free content on satellite is exactly the same as what is available OTA (DVB-T). Sky (NZ) and Foxtel (Australia) are the equivalents of Dish or DirecTV. People here use the same sorts of solutions as can be used for Dish in the US. There are some free "niche" channels available on satellite - foreign language or religious typically - but aside from that, unless you have a really big and/or motorised dish, there's nothing really worthwhile.

    On the cable front... NZ doesn't really have cable TV to speak of. There is a network in our 2nd and 3rd largest cities, but it is one provider and not being actively expanded. Basically it is considered obsolete or too expensive to expand.
    Australia I don't know so much about. They do have cable TV in big cities, but I don't think there is much choice of provider. Pretty much only Foxtel (again!).

    OTA, things are probably more similar to the US, BUT...

    In all of the above cases we get way less channels. I think I have something like 20 channels in total from OTA TV. 3 are shopping channels; 3 are +1 (ie. another channel timeshifted by an hour); 3 are foreign language. Basically there are only 5 channels I actually watch. Australia has a slightly better situation with a larger population... but still not that many channels.

    ...and things are actually getting worse. In Australia their FTA OTA channels are now encrypted on satellite (VAST), and the scheme doesn't give you a CAM (like a CableCARD) and/or smartcard you can use with a PC. No. Your subscription is tied to the STB. "Cloaked CA" they call it. Same happened in NZ with our first and only OTA pay TV provider (which is just a front for Sky). There is no subscriber card so you'd be forced to used an HD-PVR or similar to pull such content into a PC. Worse, there is no real choice of provider so they jack the prices up every year without really delivering much new and interesting content and despite quite poor customer service.

    In general I'd actually say the US has it much better with content. I mean Netflix, Hulu etc. etc. etc. We don't have anything equivalent which has such a good catalogue... and we could only dream of those prices!

    So, random thought on this, though. You said something about a theory of the SPDIF audio taking longer than usual to stream or be detected. Is it possible to increase the timeout on this in any way? I do agree with your theory, as even with streaming over UNC, there is a period of 1-2 seconds where the 'stream' starts initially with video only, followed with sound about 2 seconds later.

    It's probably not nearly as simple as adding a timeout, but I thought I'd throw it out there. Also, if you do come up with any items you'd like tested with this config, please let me know, and I'll switch back to RTSP to test them out for you.
    Without having the time to explain the technical details in depth again...
    The problem is that when you use a plugin (eg. IRSS, SHEF whatever) to control an external tuner (ie. STB + capture card), the important bits of TV Server have no way to know exactly when the "change channel" command is sent or when the external tuner has actually finished changing channel.

    A timeout would be one possible workaround (note I don't say solution!). When I say timeout I mean that you would have a setting that lets you say that the external tuner takes X seconds to change channel. When TV Server tunes, it simply waits for those X seconds before letting MP show video/audio. I really really don't like that approach, because chances are that X value has to be set a few seconds higher than otherwise necessary to account for variability in the STB tuning time, capture card processing time etc. etc. etc. It is just "feels" like a bodge/hack.

    The sort of solution I'd like to see is a solution where TV Server is able to detect when the channel change finishes. As soon as that is detected, MP starts video and audio.

    mm
     

    Users who are viewing this thread

    Top Bottom