[Help Us!] RTSP streaming library update (3 Viewers)

[mm1352000]

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:

...when I got up this morning I noticed that both clients had disconnected from the server.

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.

Hope this helps, let me know anything you want me to test.

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

 

[Charlie TV]

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

 

[mm1352000]

does this mix help at all or should i use both on RTSP?

It neither helps nor hinders, and therefore it shouldn't make any difference.

 

[Charlie TV]

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

 

[Charlie TV]

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

 

[mm1352000]

Thanks again Charlie TV

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

...so time was 4:30am (from memory)...

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

Seemed to be a file lock problem.

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:
[collapse][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] - Recorderid 19c9 Continuity error... d ( prev 3 ) - bad signal?
[2016-01-11 17:14:42,285] [7208870] [1590] - Recorderid 19ca Continuity error... 9 ( prev b ) - bad signal?
[2016-01-11 17:14:42,285] [7208870] [1590] - Recorderid 19c9 Continuity error... e ( prev 3 ) - bad signal?
[2016-01-11 17:14:42,285] [7208870] [1590] - Recorderid 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] - Recorderid 961 Continuity error... c ( prev 3 ) - bad signal?
[2016-01-11 17:14:42,799] [7208870] [1344] - Recorderid 962 Continuity error... 7 ( prev d ) - bad signal?[/collapse]

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

 

[Charlie TV]

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.

 

[Owlsroost]

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 ?

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.

 

[mm1352000]

Thanks guys

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

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?

Might be worth a look to see what the differences are.

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?

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.

I'm relieved that you agree.

 

[Owlsroost]

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?

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'