TV Recordings don't play on mobile devices but on desktop

[pünktchen 1251]

As the title says, my live tv recordings don't play on my mobile devices. Neighter in Chrome, Opera, Emby Mobile nor in Emby ATV.

But they play fine in Firefox on my desktop pc. Is it a problem with HLS?

 

Beside this main problem there are many other errors from the MediaPortal Live TV plugin in my log

 

I'm still on server version 3.0.5641.4, but it's the same with version 3.0.5675.1

[pünktchen 1251]

@@Luke I wonder whether you could have a look at this please.

[Luke 37007]

I don't really know. I think the plugin is just a little bit behind to be honest. ChubbyArse sent me some info that i haven't had a chance to digest yet.

[pünktchen 1251]

The strange thing is, it works in Firefox desktop when Emby is transcoding to webm.

When i start the recording on a mobile device the backend software (actually it is MPExtended not MediaPortals TVServer)

starts to deliver the stream, but Embys hls implementation breaks without even starting the transcoding.

That's why i thought it is more a problem of Emby than of the MediaPortal plugin?!

Edited July 25, 2015 by pünktchen

[pünktchen 1251]

This is truly a problem of Emby, isn't it?

2015-07-26 00:13:31.9601 Info - App: Live stream info: {"Protocol":"Http","Id":"502","Path":"http://localhost:4322/MPExtended/StreamingService/stream/RetrieveStream?identifier=Recording-502-20150725221331","Type":"Default","Container":"MPEG-TS","RunTimeTicks":32954800000000,"ReadAtNativeFramerate":false,"SupportsTranscoding":true,"SupportsDirectStream":true,"SupportsDirectPlay":true,"RequiresClosing":true,"LiveStreamId":"e2c02591b55c6b121fb0f65056883a50_502","MediaStreams":[],"PlayableStreamFileNames":[],"Formats":[],"RequiredHttpHeaders":{}}
2015-07-26 00:13:37.3724 Error - DtoUtils: ServiceBase<TRequest>::Service Exception
	*** Error Report ***
	Version: 3.0.5684.24675
	Command line: C:\Users\Administrator\AppData\Roaming\MediaBrowser-Server\System\MediaBrowser.ServerApplication.exe
	Operating system: Microsoft Windows NT 6.1.7601 Service Pack 1
	Processor count: 4
	64-Bit OS: True
	64-Bit Process: False
	Program data path: C:\Users\Administrator\AppData\Roaming\MediaBrowser-Server
	Application Path: C:\Users\Administrator\AppData\Roaming\MediaBrowser-Server\System\MediaBrowser.ServerApplication.exe
	Eine Ausnahme vom Typ "System.OutOfMemoryException" wurde ausgelöst.
	System.OutOfMemoryException
	   bei System.Text.StringBuilderCache.Acquire(Int32 capacity)
	   bei System.String.Format(IFormatProvider provider, String format, Object[] args)
	   bei System.String.Format(String format, Object[] args)
	   bei MediaBrowser.Api.Playback.Hls.DynamicHlsService.<GetVariantPlaylistInternal>d__35.MoveNext()

The same recording with Firefox Desktop:

2015-07-26 00:23:47.9083 Info - App: Live stream info: {"Protocol":"Http","Id":"502","Path":"http://localhost:4322/MPExtended/StreamingService/stream/RetrieveStream?identifier=Recording-502-20150725222347","Type":"Default","Container":"MPEG-TS","RunTimeTicks":32954800000000,"ReadAtNativeFramerate":false,"SupportsTranscoding":true,"SupportsDirectStream":true,"SupportsDirectPlay":true,"RequiresClosing":true,"LiveStreamId":"e2c02591b55c6b121fb0f65056883a50_502","MediaStreams":[],"PlayableStreamFileNames":[],"Formats":[],"RequiredHttpHeaders":{}}
2015-07-26 00:23:47.9883 Info - App: C:\Users\Administrator\AppData\Roaming\MediaBrowser-Server\ffmpeg\20150717\ffmpeg.exe -loglevel debug -fflags +genpts -i "http://localhost:4322/MPExtended/StreamingService/stream/RetrieveStream?identifier=Recording-502-20150725222347" -sn -codec:v:0 libvpx -force_key_frames expr:gte(t,n_forced*5) -vf "yadif=0:-1:0,scale=min(iw\,1280):trunc(ow/dar/2)*2" -pix_fmt yuv420p -speed 16 -quality good -profile:v 0 -slices 8 -crf 10 -qmin 0 -qmax 50 -maxrate:v 1372000 -bufsize:v (1372000*2) -b:v 1372000 -vsync vfr -map_metadata -1 -threads 3 -codec:a:0 libvorbis -ab 128000 -af "aresample=async=1" -y "C:\Users\Administrator\AppData\Roaming\MediaBrowser-Server\transcoding-temp\ceb5482b52eda742fb84a3c9ff3f5885.webm"

[Luke 37007]

the plugin is supplying a massive runtime for the live stream, saying the video is 38 days long. so the server is choking building a playlist of three second intervals.

[pünktchen 1251]

the plugin is supplying a massive runtime for the live stream, saying the video is 38 days long. so the server is choking building a playlist of three second intervals.

Okay understand. Thanks for clarification. Would a fixed runtime of lets say 4 hours work?

Just to know where i have to look at in the code...

[pünktchen 1251]

It's "runtimeticks" right? What is the unit of it, seconds, milliseconds? I think there's just a miscalculation in the code...

[Luke 37007]

well a live stream has no runtime so it should be left null. if it's a video then just make sure it's correct.

[pünktchen 1251]

Originally it is a video - it is a recording, but technically it is a live stream of MPExtended.

I will try runtimeticks set to zero and see how it goes.

Out of interest, still want to know the unit of runtimeticks.

Edited July 26, 2015 by pünktchen

[pünktchen 1251]

So finally i got the playback of recordings working again. MPExtended delivers the stream duration in milliseconds while ChubbyArse' code assumed it was in seconds.

 

But i still have to fix the seeking!

How do i call the seeking position of Emby?

[Luke 37007]

i don't know what you mean by that. you don't do anything on your part for seeking other than making sure the runtime is correct.

[pünktchen 1251]

I try to explain.

When you to want seek in a recording, the running stream has to be stoped and a new stream in MPExtended has to be started with the given start position in seconds:

HttpClientManager GET: http://192.168.0.3:4322/MPExtended/StreamingService/json/StartStream?identifier=Recording-504-20150723201613&profileName=Direct&startPosition=0

So there must be a way to get the desired seeking position from Emby?

 

Edit: From MPExtendeds documentation (http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/17_Extensions/Remote_Access/MPExtended/Developers/Streaming)

"It is possible to seek in a stream. Because there is no standard protocol for this, we invented our own. First stop the playing of the video (i.e. abort the request on the URL returned by StartStream). Then you can seek to another place in the video with, again, the StartStream method, but this time with the position parameter set to the new position in seconds. Make sure to use the same identifier as your previous stream."

Edited July 26, 2015 by pünktchen

[Luke 37007]

Ok, this is currently not supported. The current expectation is that the stream returned by the provider is either seekable or it's not. there's currently no support to stop and start a new stream just for the purpose of seeking. i personally would take this back to media portal and ask them to improve and eliminate that requirement. even if i were to add this ability into the server, it would force media portal live tv to always have to be transcoded by Emby server, because we are not going to put in the effort to send this requirement all the way down to client apps for the purposes of direct play.

[pünktchen 1251]

Sadly MPExtended has stopped development and no one of Team MediaPortal has a clue of it.

[Luke 37007]

Well that's unfortunate because the HLS protocol would be the answer. Perhaps some of those developers will head this way and help with Emby Live TV

[pünktchen 1251]

Okay, i've fixed playback and seeking of recordings
and also enabled concurrent streaming of MPExtended.

@@Luke is the binary enough for you to update Embys plugin catalog?

Edited July 27, 2015 by pünktchen