[Help Us!] - RTSP streaming library update | Page 5

Discussion in 'Area 51 - Testing Area' started by mm1352000, October 25, 2015.

  1. mm1352000
    • Team MediaPortal

    mm1352000 Development Group

    Joined:
    September 1, 2008
    Messages:
    21,526
    Likes Received:
    4,734
    Ratings:
    +8,200 / 17
    Home Country:
    New Zealand New Zealand
    Thanks for testing @Charlie TV

    It appears like you've configured MediaPortal to use UNC paths (SMB share) for time-shifting, as shown here:
    http://wiki.team-mediaportal.com/1_...ation/22_TV/Advanced_Options#Multi-seat_setup

    Therefore this update won't have any effect for you.

    Nevertheless, I feel like I should respond to this:
    According to the client's Windows system event log:
    "09/01/2016 09:37:17";"e1cexpress";"(0)";"Warning";"Intel(R) 82579V Gigabit Network Connection Network link is disconnected. ";"2684616731"
    "09/01/2016 09:37:19";"Service Control Manager";"(0)";"Information";"The TCP/IP NetBIOS Helper service was successfully sent a stop control. The reason specified was: 0x40030011 [Operating System: Network Connectivity (Planned)] Comment: None";"1073748866"
    "09/01/2016 09:37:19";"Service Control Manager";"(0)";"Information";"The TCP/IP NetBIOS Helper service entered the stopped state.";"1073748860"
    "09/01/2016 09:37:21";"e1cexpress";"(0)";"Information";"Intel(R) 82579V Gigabit Network Connection Network link has been established at 1Gbps full duplex. ";"1610874912"

    It looks to me like the stream was live up until that point in time. I'm not able to say why your network connection would have dropped out like that, but it doesn't seem to be anything to do with MediaPortal.

    As above: I'm grateful for your willingness to test, but unfortunately your test didn't actually "exercise" the update. You'd be welcome to switch back to RTSP and try the same test again.

    Regards,
    mm


     
    • Like Like x 2
  2. Google AdSense Guest Advertisement



    to hide all adverts.
  3. Charlie TV
    • Premium Supporter

    Charlie TV MP Donator

    Joined:
    February 22, 2014
    Messages:
    81
    Likes Received:
    10
    Ratings:
    +29 / 2
    Home Country:
    United Kingdom United Kingdom
    Great thank you :)

    I have updated the NIC drivers on the client and changed it to use RTSP, so I have left one client on UNC and now I have one on RTSP, does this mix help at all or should i use both on RTSP?

    Cheers
     
  4. mm1352000
    • Team MediaPortal

    mm1352000 Development Group

    Joined:
    September 1, 2008
    Messages:
    21,526
    Likes Received:
    4,734
    Ratings:
    +8,200 / 17
    Home Country:
    New Zealand New Zealand
    It neither helps nor hinders, and therefore it shouldn't make any difference.
     
  5. Charlie TV
    • Premium Supporter

    Charlie TV MP Donator

    Joined:
    February 22, 2014
    Messages:
    81
    Likes Received:
    10
    Ratings:
    +29 / 2
    Home Country:
    United Kingdom United Kingdom
    Cool no problem. Both are now RTSP and streaming different HD channels I'll let you know if I find any issues

    Thanks for all your help and ongoing work :)
     
    • Like Like x 1
    • Thank You! Thank You! x 1
  6. Charlie TV
    • Premium Supporter

    Charlie TV MP Donator

    Joined:
    February 22, 2014
    Messages:
    81
    Likes Received:
    10
    Ratings:
    +29 / 2
    Home Country:
    United Kingdom United Kingdom
    Hi guys

    I had a frozen screen on the TV client the image was on a news channel so time was 4:30am (from memory) the client was active in that the menus worked but I couldn't view a channel and it would come up with a buffer error. Seemed to be a file lock problem. I took log files from the client and server. The 17:14 Server I took in the frozen state, I had to stop and start the service to make it work again and took another log capture at 17:19.

    Hope it's helpful and not a false positive :)

    Cheers
     
    • Thank You! Thank You! x 1
  7. mm1352000
    • Team MediaPortal

    mm1352000 Development Group

    Joined:
    September 1, 2008
    Messages:
    21,526
    Likes Received:
    4,734
    Ratings:
    +8,200 / 17
    Home Country:
    New Zealand New Zealand
    Thanks again Charlie TV (y)

    I can see what you mean and this time it's definitely not a false positive.

    Yep, the client log file approximately agrees:
    [2016-01-11 04:23:55,015] [Log ] [MPMain ] [DEBUG] - VMR9Helper: Playing -> Repainting, Frames 0

    Yep, the server's log files seem to agree. In the TV service log we have:
    [2016-01-11 17:17:27,879] [Log ] [33 ] [DEBUG] - Controller: Error "The process cannot access the file 'E:\live9-0.ts.tsbuffer' because it is being used by another process." on delete in CleanTimeshiftFiles
    ...
    [2016-01-11 17:17:28,113] [Log ] [33 ] [DEBUG] - Controller: Error "The process cannot access the file 'E:\live9-0.ts.tsbuffer8.ts' because it is being used by another process." on delete in CleanTimeshiftFiles

    ...and in the TsWriter log we have approximately the same entries repeating ad nauseum:
    Show Spoiler
    [2016-01-11 17:14:42,035] [7208870] [1344] - Recorder: TIMESHIFT Info : Program clock reference forward jump ( 47054 ).
    [2016-01-11 17:14:42,285] [7208870] [1344] - MultiFileWriter: failed to create file E:\\live12-0.ts.tsbuffer3.ts
    [2016-01-11 17:14:42,285] [7208870] [1344] - Failed to reopen old file. It's currently in use. Dropping data!
    [2016-01-11 17:14:42,285] [7208870] [1590] - Recorder:pid 19c9 Continuity error... d ( prev 3 ) - bad signal?
    [2016-01-11 17:14:42,285] [7208870] [1590] - Recorder:pid 19ca Continuity error... 9 ( prev b ) - bad signal?
    [2016-01-11 17:14:42,285] [7208870] [1590] - Recorder:pid 19c9 Continuity error... e ( prev 3 ) - bad signal?
    [2016-01-11 17:14:42,285] [7208870] [1590] - Recorder:pid 19ca Continuity error... f ( prev a ) - bad signal?
    [2016-01-11 17:14:42,441] [7208870] [1590] - MultiFileWriter: failed to create file E:\\live9-0.ts.tsbuffer8.ts
    [2016-01-11 17:14:42,441] [7208870] [1590] - Failed to reopen old file. It's currently in use. Dropping data!
    [2016-01-11 17:14:42,799] [7208870] [1344] - Recorder:pid 961 Continuity error... c ( prev 3 ) - bad signal?
    [2016-01-11 17:14:42,799] [7208870] [1344] - Recorder:pid 962 Continuity error... 7 ( prev d ) - bad signal?


    The TsWriter log file doesn't run back to 4:30 AM so I can't be sure of this, but I think that this file locking may be caused by the streaming server. Streaming server is logging the entries like this repeatedly starting at ~3:30 AM:
    11-01-2016 03:33:38.322 Abnormal start PCR, endPcr 128305, startPcr 8144303237
    11-01-2016 03:33:38.342 Abnormal start PCR, endPcr 128305, startPcr 8144303237
    11-01-2016 03:33:38.363 Abnormal start PCR, endPcr 128305, startPcr 8144303237
    11-01-2016 03:33:38.384 Abnormal start PCR, endPcr 134613, startPcr 8144303237
    11-01-2016 03:33:38.405 PCR rollover normally found ! endPcr 134613, startPcr 8144303237

    This is nothing to do with my changes, but does indicate that there's probably a [loooong standing] bug or limitation in streaming server when it comes to streaming continuously for long periods of time. I'm not sure that I can or should do anything about this within the context of this update. The update is already quite significant. The bigger it gets, the harder it is to manage and test properly. What do you think @Owlsroost ?

    Anyhow, the last thing I noticed - which may or may not be connected to some/all of the above stuff - are the following entries in the TsReader log:
    [2016-01-11 03:44:24,179] [3e9e94b0] [ 690] - CRTSPClient::UpdateDuration(): RTSP DESCRIBE timed out, message = liveMedia6

    There are ~1500 of them followed by ~10000 of the following entries:
    [2016-01-11 05:30:53,117] [3e9e94b0] [ 690] - CRTSPClient::UpdateDuration(): RTSP DESCRIBE failed, result code = -10035, message = DESCRIBE send() failed: A non-blocking socket operation could not be completed immediately

    These entries directly relate to the changes I've made, so they're a bit concerning. If they're connected to the streaming server PCR rollover stuff then it's possible that there's nothing I can do about them (ie. they're just a symptom of the streaming server problem). However I'd like to try a modification and see if it makes any difference. To that end, please could you try the same test with the attached TsReader update.

    Thanks again for testing!
    Regards,
    mm
     

    Attached Files:

    • Thank You! Thank You! x 2
  8. Charlie TV
    • Premium Supporter

    Charlie TV MP Donator

    Joined:
    February 22, 2014
    Messages:
    81
    Likes Received:
    10
    Ratings:
    +29 / 2
    Home Country:
    United Kingdom United Kingdom
    Cheers thank you. I have cleared out all the logs and installed the update. Yes I agree there is probably a long standing bug somewhere, I don't notice the problem if I have just 1x client streaming but when I have 2x clients streaming I've experienced the lock problem in the past, so don't think it's your changes :)

    I will let you know how it goes, thanks for your help.
     
    • Like Like x 1
    • Thank You! Thank You! x 1
  9. Owlsroost
    • Team MediaPortal

    Owlsroost Development Group

    Joined:
    October 28, 2008
    Messages:
    5,537
    Likes Received:
    2,828
    Location:
    Cambridge
    Ratings:
    +4,130 / 1
    Home Country:
    United Kingdom United Kingdom
    Show System Specs
    Many moons ago (before I got involved in it, at least) there were some changes done to the PCR handling and rollover code in TsReader (I think it was in relation to playing files from a third-party TV server, which didn't - at that time - start each recorded file at PCR = 0, like ours does. So rollovers occurred during playback sometimes - and seeking didn't work properly if this happened...). Might be worth a look to see what the differences are.

    Since this is the first time I remember this coming up as a problem (using RTSP) I don't think it feels like an urgent problem to fix for this update.
     
    • Like Like x 1
    • Thank You! Thank You! x 1
  10. mm1352000
    • Team MediaPortal

    mm1352000 Development Group

    Joined:
    September 1, 2008
    Messages:
    21,526
    Likes Received:
    4,734
    Ratings:
    +8,200 / 17
    Home Country:
    New Zealand New Zealand
    Thanks guys :)

    That's interesting, because the 2 clients should be using separate buffer files... unless you were using a non-MediaPortal front-end and intentionally connecting both clients to a single stream?

    Hmmmm. Honestly I find buffer and timing handling a bit overwhelming. I learnt a lot from the couple of PCR patches I did for TsWriter, but this would be a whole new level of complexity. Don't know if I'm capable. Instead of attempting to fix streaming server in isolation, I'm wondering whether it would be smarter/helpful/possible to port (or even share) code from TsReader. FileReader, MultiFileReader, TsDuration, TsFileSeek... those classes are common to both projects, and if I'm not wrong they're also the classes that are responsible for low-level buffer and PCR handling. Do you think that would be feasible and/or appropriate?

    I'm relieved that you agree. ;)
     
    • Like Like x 1
  11. Owlsroost
    • Team MediaPortal

    Owlsroost Development Group

    Joined:
    October 28, 2008
    Messages:
    5,537
    Likes Received:
    2,828
    Location:
    Cambridge
    Ratings:
    +4,130 / 1
    Home Country:
    United Kingdom United Kingdom
    Show System Specs
    Yes, that would be a good place to start from. In fact the StreamingServer version that is in my merged experimental branch - https://github.com/MediaPortal/MediaPortal-1/tree/EXP-Upgrade_555_MM_Owlsroost - already has the MultiFileReader code from TsReader (the version in that branch) ported to it. I've not looked at it in detail, but I think the classes you mention were originally the same code - they have just diverged over the years - so porting across the TsReader version should be feasible/probably a good idea.

    I'll put it on my list of 'things to look at' :)
     
    • Like Like x 2
    • Thank You! Thank You! x 2
Loading...

Users Viewing Thread (Users: 0, Guests: 0)

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice
  • About The Project

    The vision of the MediaPortal project is to create a free open source media centre application, which supports all advanced media centre functions, and is accessible to all Windows users.

    In reaching this goal we are working every day to make sure our software is one of the best.

             

  • Support MediaPortal!

    The team works very hard to make sure the community is running the best HTPC-software. We give away MediaPortal for free but hosting and software is not for us.

    Care to support our work with a few bucks? We'd really appreciate it!