How to trigger RecordingStatusChanged event

[pünktchen 1258]

I'd like to trigger RecordingStatusChanged after timer creation. Any insights how to do this?

Thanks in advance!

[Luke 37046]

Don't do that if it's in response to a timer being created by Emby. It's not necessary and won't have any value. If you want to report a timer has been created externally, it could have value, but we should create a separate event so that we don't refresh the whole guide just for that.

 

You only trigger this event when the guide needs to be refreshed, so we're talking major changes like guide data configuration change, tuner hardware change, etc.

[pünktchen 1258]

Ah, okay. I've thought there's a refresh problem with in-progress recordings and that RecordingStatusChanged would help here...

But i think i've found the root cause why recordings don't playback any longer:

public Task<MediaSourceInfo> GetRecordingStream(string recordingId, string streamId, CancellationToken cancellationToken)

doesn't return recordingId anymore! Has something changed in beta or dev, that i need to know?

[Luke 37046]

What do you mean doesn't return recording id?

[pünktchen 1258]

I mean the recordingId is just empty (btw. streamId is also empty, but i don't need this currently). I don't know when this started, because i don't take every beta update. But it must be a change in the last seven days i think.

If i start playback of recordings in of the apps, Emby is calling GetRecordingStream in the plugin. The recordingId is then passed as a parameter to further methods, which start streaming of the recordings in the tv backend. Without this id no streaming is possible.

A picture says more than words:

 

[Spaceboy 2493]

also having this problem, no playback of in progress recordings in android tv

[Luke 37046]

It's being looked into, thanks.

[Spaceboy 2493]

also having this problem, no playback of in progress recordings in android tv

now working again although i am still seeing occasional regular situations where playback of in progress recordings ends early when the same file plays back fine once complete and fully detected. using mxplayer cheers

Edited November 17, 2016 by Spaceboy

[pünktchen 1258]

now working again although i am still seeing occasional regular situations where playback of in progress recordings ends early when the same file plays back fine once complete and fully detected. using mxplayer cheers

This will hopefully get better when all apps get timeshifting.

[Luke 37046]

I don't recommend doing in-progress recordings with an external player. It's one of those things that should work, but since we have no ability to debug what's going on in the player it's hard for us to provide any kind of support on it.

[Spaceboy 2493]

I don't recommend doing in-progress recordings with an external player. It's one of those things that should work, but since we have no ability to debug what's going on in the player it's hard for us to provide any kind of support on it.

mmm i'd love to be able to use either of the internal options but neither work for UK DVBS2 unfortunately

[Spaceboy 2493]

now working again although i am still seeing occasional regular situations where playback of in progress recordings ends early when the same file plays back fine once complete and fully detected. using mxplayer cheers

ok, this seems to be highly linked to the actual recording finishing. playback of the in progress recording seems to end early at that point. would a log help diagnose the situation?

[pünktchen 1258]

ok, this seems to be highly linked to the actual recording finishing. playback of the in progress recording seems to end early at that point. would a log help diagnose the situation?

 

No, a log wouldn't help here.

You are still talking about playback on Android, right? As mentioned before it should work in browsers already and you just have to wait until timeshifting gets ported to the other apps.

 

Some technical background about current situation:

Beside Kodi nearly no other Android player is able to directly open a file from a smb share. You always need a smb client that handles your request. (for example via ES File Explorer).

That's the reason why Emby (even if you think it's direct playing) streams your recordings via http to the players.

But i cannot feed Emby with the actual file path of an inprogress recording, because Emby refuses to open a file that is still growing.

What i'm doing now is, i let MPExtended stream the recording right from the beginning and feed Emby with the streaming url.

Emby is now reading the MPExtended stream as fast as possible and if it reaches the end of the stream (not necessarily the end of the recording), it just quits!

To prevent this from happening, i'm saying to Emby "read the stream at it's native framerate". But unfortunately this is not accurate!

 

With timeshifting enabled via browser playback, Emby doesn't quit anymore at the end of the stream.

Instead Emby is waiting until another packet arrives and writes this to a local file.This file in turn is then streamed to the player and you are able to seek within this file.

[Luke 37046]

because Emby refuses to open a file that is still growing.

 

Emby doesn't refuse anything. You are free to pass the file path if you wish, however ffmpeg doesn't support this. It reads the duration when it first opens the file which means in the middle of the recording it will stop because it thinks it has reached the end of the file. Even with the read at native framerate option it will still reach the end. So you can pass the file if you want, but then when it cuts out you're just going to say "emby not working". (And hopefully you won't spread mis-information around causing people think "not working").

 

The way to handle this situation is to pass something into ffmpeg that is not seekable, such as an http stream, therefore it's unable to read the duration and will just stream indefinitely.

[pünktchen 1258]

Emby doesn't refuse anything. You are free to pass the file path if you wish, however ffmpeg doesn't support this. It reads the duration when it first opens the file which means in the middle of the recording it will stop because it thinks it has reached the end of the file. Even with the read at native framerate option it will still reach the end. So you can pass the file if you want, but then when it cuts out you're just going to say "emby not working". (And hopefully you won't spread mis-information around causing people think "not working").

 

You are just nitpicking here. I know it's ffmpeg. But isn't Emby utilizing ffmpeg?!

It's like you are saying "My Apple device has a bad display" and Apple answers "It's not us, it is Samsung - they are making our displays". The comsumers don't care about the detailed insights...

 

 

The way to handle this situation is to pass something into ffmpeg that is not seekable, such as an http stream, therefore it's unable to read the duration and will just stream indefinitely.

 

Please read my post again. This is exactly what i'm doing already in combination with "read at native framerate", but it's still not working every time for the user.

[Luke 37046]

Thanks, I figured. Just making sure the readers know

[Spaceboy 2493]

No, a log wouldn't help here.

You are still talking about playback on Android, right? As mentioned before it should work in browsers already and you just have to wait until timeshifting gets ported to the other apps.

 

Some technical background about current situation:

Beside Kodi nearly no other Android player is able to directly open a file from a smb share. You always need a smb client that handles your request. (for example via ES File Explorer).

That's the reason why Emby (even if you think it's direct playing) streams your recordings via http to the players.

But i cannot feed Emby with the actual file path of an inprogress recording, because Emby refuses to open a file that is still growing.

What i'm doing now is, i let MPExtended stream the recording right from the beginning and feed Emby with the streaming url.

Emby is now reading the MPExtended stream as fast as possible and if it reaches the end of the stream (not necessarily the end of the recording), it just quits!

To prevent this from happening, i'm saying to Emby "read the stream at it's native framerate". But unfortunately this is not accurate!

 

With timeshifting enabled via browser playback, Emby doesn't quit anymore at the end of the stream.

Instead Emby is waiting until another packet arrives and writes this to a local file.This file in turn is then streamed to the player and you are able to seek within this file.

hello, does it change anything if i now report that playback of all in progress recordings always stop when the recording stops and never under any other circumstances. so its actually when the file stops growing that it goes wrong. when this happens all you can do is go to the recordings screen and keep refreshing the recording until emby picks up the full details of recording time. at that point you can then navigate through the recording back to the point where it stopped but it can take anywhere between 1 and up to 20 mins on occasion

[Luke 37046]

Currently Emby just uses a 5-minute cache without any kind of intelligence. This has the drawback of both refreshing when not needed, and not refreshing when it is needed.

 

@@pünktchen, are you able receive notifications from the tv server to the plugin? If you can, and if we can get these events working, then we can have a nice long cache period with immediate refreshing when it is needed.

[pünktchen 1258]

hello, does it change anything if i now report that playback of all in progress recordings always stop when the recording stops and never under any other circumstances. so its actually when the file stops growing that it goes wrong. when this happens all you can do is go to the recordings screen and keep refreshing the recording until emby picks up the full details of recording time. at that point you can then navigate through the recording back to the point where it stopped but it can take anywhere between 1 and up to 20 mins on occasion

Are you still using the plugin version of this post: https://emby.media/community/index.php?/topic/41088-Last-Few-Problems&do=findComment&comment=385058

[pünktchen 1258]

 

 

@@pünktchen, are you able receive notifications from the tv server to the plugin? If you can, and if we can get these events working, then we can have a nice long cache period with immediate refreshing when it is needed.

Not that i know. I'll have to investigate it.

[Luke 37046]

If there is nothing, it might be cheaper to have the plugin poll the tv server every 60 seconds and trigger the event if needed, then we can cache for long periods of time and react to change quicker....as opposed to the current 5 minute cache.

[Spaceboy 2493]

Are you still using the plugin version of this post: https://emby.media/community/index.php?/topic/41088-Last-Few-Problems&do=findComment&comment=385058

i could have been, it wasnt easy to tell what version that was. but i wasnt on the latest version so i've upgraded. Should this solve the issue? it'll be a few days before i can test

[pünktchen 1258]

If there is nothing, it might be cheaper to have the plugin poll the tv server every 60 seconds and trigger the event if needed, then we can cache for long periods of time and react to change quicker....as opposed to the current 5 minute cache.

What should i poll, timers or recordings?

 

Also some other interesting observations of in progress recordings:

If i provide the file path of a recording (not a streaming url) in conjunction with "ReadAtNativeFramerate", playback quits after reaching the runtime that was detected at playback start.

This is normal behaviour with ffmpeg i've thought. But if i set "SupportsProbing" to false, the in progress recording plays forever! So ffmpeg itself doesn't seem to have a problem with a still growing file.

Any explanation for this?

 

The only real differences in ffmpeg command line parameters are these:

With probing              -maxrate 616000 -bufsize 1232000 -copyts -max_delay 5000000 -avoid_negative_ts disabled -start_at_zero

Without probing         -maxrate 1808000 -bufsize 3616000 -fflags +genpts -sc_threshold 0

[Luke 37046]

i think if you gave it a file path and enabled probing it probably thought it was a fixed length file based on the duration at the time of the probe.

[pünktchen 1258]

That was my guess also. The only runtime i see in the logs with probing enabled is "RunTimeTicks" from media source info.

So i've set a custom value for RunTimeTicks, that represents the full recording length. Unfortunately this isn't respected, neighter with probing enabled, nor with probing disabled.

Can you change this please, so if we already deliver some media source infos, that they take priority?