Jump to content

API: allow duration to be supplied for strm files (to allow resume)


horstepipe
 Share

Recommended Posts

Modified the request because we already have the ability to create a resume point for any item.  What you need is the ability for the duration to somehow be supplied externally.

  • Like 2
Link to comment
Share on other sites

ddurdle

I'm confused.  If the resume point can be created for any item, then can you provide steps on creating it for a STRM?

Link to comment
Share on other sites

I'm confused.  If the resume point can be created for any item, then can you provide steps on creating it for a STRM?

 

Resume points are created by reporting a position when you stop something.  The problem with strm files is they have no duration and, therefore, the resume point does not get created.  So, what is needed is a way to supply the duration of the strm file.

Link to comment
Share on other sites

  • 2 months later...
horstepipe

Resume points are created by reporting a position when you stop something.  The problem with strm files is they have no duration and, therefore, the resume point does not get created.  So, what is needed is a way to supply the duration of the strm file.

So there has some work to be done on Emby Server AND (Emby for Kodi) client to make this work?

@@Luke

As I see you‘re currently doing something regarding strm files, maybe you could put this on your list, too?

 

Best regards

  • Like 1
Link to comment
Share on other sites

  • 3 months later...
ddurdle

Resume points are created by reporting a position when you stop something.  The problem with strm files is they have no duration and, therefore, the resume point does not get created.  So, what is needed is a way to supply the duration of the strm file.

 

 

When you playback a http stream in other plays (VLC, KODI, quicktime player etc), the duration is fetched from the file itself.  I have analyzed further the fetches being done, and I can see these players will detect that the response incoming stream is a MP4 file for application-stream type, and will automatically then perform the analysis by requesting the size of the file, and then attempting to read the media information either at the start of the file or at the end of the file.

 

This is definitely doable and should be easy if we include that check if the stream being returned is a media file.

Edited by ddurdle
  • Like 2
Link to comment
Share on other sites

@@ddurdle Theater MPV test version, gives you the option to get a log from the strm content that is played in Theater MPV.

I just looked at the logs what is fetched and duration of the content played is one of them, even as ALL embedded subtracks, that Theater MPV doesn't show in the available subtracks during play.

 

Attached the log from the movie "6 days" (loaded by strm file from Emby library) which has a duration of 1h 34 minutes according to IMDB and Theater MPV fetches this information within 0.367s, assuming that first column in log is the timestamp.

[   0.367][v][mkv] | + duration: 5674.154s

So we can do the math here: 5674.154/60 = 1h 34m

 

It would be awsome if Emby devs (@@Luke, @ebr) built some code to probe strm files in a library scan, so Emby server can be supplied with all the relevant data that it needs for resuming, subtitles etc, just like channel probing is done with the m3utuner for iptv in Emby.

Theater mpv log.txt

Edited by Senna
Link to comment
Share on other sites

ddurdle

@@ddurdle Theater MPV test version, gives you the option to get a log from the strm content that is played in Theater MPV.

I just looked at the logs what is fetched and duration of the content played is one of them, even as ALL embedded subtracks, that Theater MPV doesn't show in the available subtracks during play.

 

Attached the log from the movie "6 days" (loaded by strm file from Emby library) which has a duration of 1h 34 minutes according to IMDB and Theater MPV fetches this information within 0.367s, assuming that first column in log is the timestamp.

[   0.367][v][mkv] | + duration: 5674.154s

So we can do the math here: 5674.154/60 = 1h 34m

 

It would be awsome if Emby devs (@@Luke, @ebr) built some code to probe strm files in a library scan, so Emby server can be supplied with all the relevant data that it needs for resuming, subtitles etc, just like channel probing is done with the m3utuner for iptv in Emby.

 

 

Good analysis.  I started thinking about going down the same route.  I have some accompanying scripts that can be installed on an Emby that lets you link up Google Drive library.  I don't like the mount route where you mount your Google Drive to the OS and then have Emby treat it as a media source.  When done properly, Emby hands the stream url to the client and he direct plays it from Google Drive.  This relieves stress om the Emby Server for delivery of the content.  I'm able to track the position the user is in the playback and record this in the user's account.  But again, when the user wants to resume it, I have no way of telling Emby to skip ahead to that position in the stream.

 

The best approach would be Emby sees the application-stream as the file it is along with the duration and other media meta information attached to the file.  Not only will this give Emby the duration, but when Emby has a restore point, it'll know precisely which bytes to skip to in the file.  

 

It would be simple and clean.  And it wouldn't be any different then how Emby skips ahead in files that are local MP4 files.  It'd just translate the byte start position to the equivalent in a resumable http call.  If the source doesn't support byte ranges, then it just defaults to what it does today -- treat it as a dumb stream of incoming bytes.

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...
horstepipe

When you playback a http stream in other plays (VLC, KODI, quicktime player etc), the duration is fetched from the file itself.  I have analyzed further the fetches being done, and I can see these players will detect that the response incoming stream is a MP4 file for application-stream type, and will automatically then perform the analysis by requesting the size of the file, and then attempting to read the media information either at the start of the file or at the end of the file.

 

This is definitely doable and should be easy if we include that check if the stream being returned is a media file.

@@Luke

Please be so kind and take a little time to get in touch with @@ddurdle so you can figure out how to integrate this in Emby Server. He is very willing to help. Maybe @@Angelblue05 should participate for the needed changes in Emby for Kodi.

This is the last hurdle to have a perfect experience with strm files.

  • Like 1
Link to comment
Share on other sites

I don't think we should scan these during the library scan, but rather just prior to playback, when it is needed.

Link to comment
Share on other sites

fneves

I don't think we should scan these during the library scan, but rather just prior to playback, when it is needed.

 

Wouldn't it make it more efficient it was already scanned at library time? But I understand, the file might change later, but oh well. Could be an option tho :)

Link to comment
Share on other sites

The actual videos are hosted on an external domain (typically). Doing it at scan time would hammer that domain. Doing it at playback time will work just fine.

  • Like 1
Link to comment
Share on other sites

fneves

The actual videos are hosted on an external domain (typically). Doing it at scan time would hammer that domain. Doing it at playback time will work just fine.

 

That wouldn't be a problem, but I understand your point. As long as we have a solution, it's fine by me :)

  • Like 1
Link to comment
Share on other sites

ddurdle

The actual videos are hosted on an external domain (typically). Doing it at scan time would hammer that domain. Doing it at playback time will work just fine.

 

Yes, I agree with that.  A very good point.  Yes, perhaps store the fact there is no duration, but then during playback if the result returns a duration length, then record this.

 

This would be an muchly appreciated tweak by quite a few users :)

Edited by ddurdle
Link to comment
Share on other sites

Senna

First, Thank You @Luke for adding strm probing in 3.3.1.4 :D

 

The actual videos are hosted on an external domain (typically). Doing it at scan time would hammer that domain.

I'm using a "m3u to strm" export tool for iptv VOD content. Next to that strm export tool, I'm also using a m3u stream tester tool for months now, to check if  iptv channels or iptv VOD channels are still online.

 

So this tool also "hammers" my iptv provider and this tool checks ONE stream URL from m3u at a time, at intervals of around 1-2 seconds by playing the stream for 1-2 seconds. All the stream that doesn't load (are dead/not online), those dead lines are exported to a report file, when the stream batch check is finished.

 

So far, I didn't have any problems or emails from my iptv provider or locking of my iptv subscription for months already I have been using this stream tester tool. I did batches of 100, 200, 500 URL's from m3u to check and never got any problems with it from my iptv provider.

 

So with the information above, it should make way for building something into Emby what works best, to incorporate a batch scan for strm content:

 

- which ONLY scans strm content which HASN'T been probed before

- where settings are present to set the intervals of each probe, like 2 seconds

- where settings are present for the amount of strm files to be probed in one batch

 

If those conditions are met, than batch scan of strm content can be done safely, because the infra structure of an iptv provider is already setup for people who are zapping channels (which is the same the stream tester tool I mentioned, is doing right now).

Edited by Senna
Link to comment
Share on other sites

horstepipe

Hey

@@Luke @@Angelblue05

 

I saw that in the current beta you implemented the request, thank you!

Unfortunately I don’t see any changed behavior in Kodi, movies are marked as watched regardless of how much the progress is.

Angelblue05, do you need to adjust it in Emby for Kodi?

Link to comment
Share on other sites

First, Thank You @Luke for adding strm probing in 3.3.1.4 :D

 

I'm using a "m3u to strm" export tool for iptv VOD content. Next to that strm export tool, I'm also using a m3u stream tester tool for months now, to check if  iptv channels or iptv VOD channels are still online.

 

So this tool also "hammers" my iptv provider and this tool checks ONE stream URL from m3u at a time, at intervals of around 1-2 seconds by playing the stream for 1-2 seconds. All the stream that doesn't load (are dead/not online), those dead lines are exported to a report file, when the stream batch check is finished.

 

So far, I didn't have any problems or emails from my iptv provider or locking of my iptv subscription for months already I have been using this stream tester tool. I did batches of 100, 200, 500 URL's from m3u to check and never got any problems with it from my iptv provider.

 

So with the information above, it should make way for building something into Emby what works best, to incorporate a batch scan for strm content:

 

- which ONLY scans strm content which HASN'T been probed before

- where settings are present to set the intervals of each probe, like 2 seconds

- where settings are present for the amount of strm files to be probed in one batch

 

If those conditions are met, than batch scan of strm content can be done safely, because the infra structure of an iptv provider is already setup for people who are zapping channels (which is the same the stream tester tool I mentioned, is doing right now).

 

This is the same as with images.  There is just no reason to incur the bandwidth, processing and other costs involved (both by your system and whomever is hosting the content) to obtain expensive data that may never be needed.

 

(by expensive, I mean in terms of size - this isn't a quick hit with a 3 byte response)

Link to comment
Share on other sites

Senna

Well that quick hit for the only info we need with strm, only takes roughly 1 second:

 

For duration:

[   1.047][v][mkv] | + duration: 5781.930s

For embedded subs:

[   1.069][i][cplayer]  (+) Subs  --sid=1 --slang=ara (*) (subrip)
[   1.069][i][cplayer]      Subs  --sid=2 --slang=bul (subrip)
[   1.069][i][cplayer]      Subs  --sid=3 --slang=ben (subrip)
[   1.069][i][cplayer]      Subs  --sid=4 --slang=bos (subrip)
[   1.069][i][cplayer]      Subs  --sid=5 --slang=cze (subrip)
[   1.069][i][cplayer]      Subs  --sid=6 --slang=srp (subrip)
[   1.069][i][cplayer]      Subs  --sid=7 --slang=dan (subrip)
[   1.069][i][cplayer]      Subs  --sid=8 --slang=ger (subrip)
[   1.069][i][cplayer]      Subs  --sid=9 --slang=gre (subrip)
[   1.069][i][cplayer]      Subs  --sid=10 --slang=eng (subrip)
[   1.069][i][cplayer]      Subs  --sid=11 --slang=spa (subrip)
[   1.069][i][cplayer]      Subs  --sid=12 --slang=est (subrip)
[   1.069][i][cplayer]      Subs  --sid=13 --slang=per (subrip)
[   1.069][i][cplayer]      Subs  --sid=14 --slang=fin (subrip)
[   1.069][i][cplayer]      Subs  --sid=15 --slang=fre (subrip)
[   1.069][i][cplayer]      Subs  --sid=16 --slang=heb (subrip)
[   1.069][i][cplayer]      Subs  --sid=17 --slang=hrv (subrip)
[   1.069][i][cplayer]      Subs  --sid=18 --slang=hun (subrip)
[   1.069][i][cplayer]      Subs  --sid=19 --slang=ind (subrip)
[   1.069][i][cplayer]      Subs  --sid=20 --slang=ita (subrip)
[   1.069][i][cplayer]      Subs  --sid=21 --slang=mac (subrip)
[   1.069][i][cplayer]      Subs  --sid=22 --slang=mal (subrip)
[   1.069][i][cplayer]      Subs  --sid=23 --slang=dut (subrip)
[   1.069][i][cplayer]      Subs  --sid=24 --slang=nor (subrip)
[   1.069][i][cplayer]      Subs  --sid=25 --slang=por (subrip)
[   1.069][i][cplayer]      Subs  --sid=26 --slang=pol (subrip)
[   1.069][i][cplayer]      Subs  --sid=27 --slang=por (subrip)
[   1.069][i][cplayer]      Subs  --sid=28 --slang=rum (subrip)
[   1.069][i][cplayer]      Subs  --sid=29 --slang=rus (subrip)
[   1.070][i][cplayer]      Subs  --sid=30 --slang=slv (subrip)
[   1.070][i][cplayer]      Subs  --sid=31 --slang=swe (subrip)
[   1.070][i][cplayer]      Subs  --sid=32 --slang=tam (subrip)
[   1.070][i][cplayer]      Subs  --sid=33 --slang=tha (subrip)
[   1.070][i][cplayer]      Subs  --sid=34 --slang=tur (subrip)
[   1.070][i][cplayer]      Subs  --sid=35 --slang=vie (subrip)
[   1.070][i][cplayer]      Subs  --sid=36 --slang=chi (subrip)

Edited by Senna
Link to comment
Share on other sites

horstepipe

Hey

@@Luke @@Angelblue05

 

I saw that in the current beta you implemented the request, thank you!

Unfortunately I don’t see any changed behavior in Kodi, movies are marked as watched regardless of how much the progress is.

Angelblue05, do you need to adjust it in Emby for Kodi?

 

sorry forget about it, I took the old beta.

@@Luke will you provide beta 3.3.1.4 for linux, too?

Link to comment
Share on other sites

ddurdle

@@Luke is the man.

 

I was pointed to 3.3.1.4 magic incoming this morning before the linux build was ready.  Saw the notification.  Installed.

 

Saw right away that duration is appearing in the console when playback is happening.  Also saw the video and audio codec information being displayed with content.  

 

Not entirely sure if resume points is in or not, or how to use it.  But I'm playing around with the new found magic in 3.3.1.4.

 

Oh, and FYI, I had no issue with it playing back Google Drive content, didn't hammer my cloud install, etc.  Ran beautiful.

 

EDIT:  resume points are working fabulous on my Google Drive media. 

 

Excellent job well done!

Edited by ddurdle
  • Like 1
Link to comment
Share on other sites

horstepipe

okay went on testing in Kodi, looks like as soon as Emby server got the runtime of a strm-file, you can't skip more than 10 seconds while playback and resuming in Kodi doesn't work either.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...