Advice on which streaming method to use

[mvallevand]

I've made an addition to the /live calls for the next release, where you can override the mime type with an option "mime" request parameter. ie, http://127.0.0.1:8866/live?recording=123...tion/octet

Will that be &mime=application%2foctet

Martin

[mvallevand]

So I followed subs advice to read (carefully this time) web.log where I think I've eventually found the answer.
The LG player makes an initial byte range call, probably to determine if the server supports seeking. It asks for byte 4001 to 4500 and expects 500 bytes in return.
/stream returns 500 bytes while /live only returns 499 which I guess causes the player to block seeking.

/Fred

Sub and I had a lot of trouble getting this one byte figured out for the NMT it might explain some xbmc woes too.

A great tool is to turn off the recording service and use NRecord RUN you get a lot more info on what is going on.

Martin

[fred250]

Sub and I had a lot of trouble getting this one byte figured out for the NMT it might explain some xbmc woes too.

Hmm, out of curiosity, why would this one byte make a difference except when querying a specific small range of bytes. Most of the time the range is larger than what fits into a “chunk” and the client gets a of number bytes, how many is decided on the server. Of course a mismatch between header and payload may confuse the client.

A great tool is to turn off the recording service and use NRecord RUN you get a lot more info on what is going on.

Thanks for the tip!

/Fred

[mvallevand]

Fred here's one of the old threads http://forums.nextpvr.com/showthread.php...post263265 the one byte caused real performance issues.

Martin

[sub]

Will that be &mime=application%2foctet

When I tested it, the browser didn't need me to escape this. It can probably handle it either way though.

[sub]

So I followed subs advice to read (carefully this time) web.log where I think I've eventually found the answer.
The LG player makes an initial byte range call, probably to determine if the server supports seeking. It asks for byte 4001 to 4500 and expects 500 bytes in return.
/stream returns 500 bytes while /live only returns 499 which I guess causes the player to block seeking.

/Fred

What exactly do the range requests look like from this play?

[sub]

I've made a change for the next release which should return the number of bytes your player is expecting.

[fred250]

Thanks Sub,
I'm looking forward to test it.

But... I'm probably gonna need a stream by filename option anyway. Files like .edl, .srt and possibly others needs to be accessible to the client if to match native NextPVR and MNT.
As you know, many players natively access subtitle files by just replacing the extension.

If you decide to implement the filename option you shouldn’t have any problems allowing for long accented filenames. I use Uri.UnescapeDataString(filename) (.NET 4.5) with my Swedish filenames (same ones failing in /stream) no problem.

Below is what shows in web.log when the player is requesting the range using both /stream and /live.

Code:

2013-09-12 23:02:00.445    [DEBUG][4]    Got Web Request (192.168.0.99): /stream    f=D%3A%5CServerFolders%5CRecorded+TV%5CDouble+Your+House+for+Half+the+Money%5CDouble+Your+House+for+Half+the+Money_20130910_21002200.ts
2013-09-12 23:02:00.446    [DEBUG][4]    SharedMemoryHelper::Open()
2013-09-12 23:02:00.447    [DEBUG][4]    Unable to find in 'Global', about to check 'Local'
2013-09-12 23:02:00.447    [DEBUG][4]    Unable to find in either 'Global' or 'Local'
2013-09-12 23:02:00.447    [DEBUG][4]    RollingFile(D:\ServerFolders\Recorded TV\Double Your House for Half the Money\Double Your House for Half the Money_20130910_21002200.ts)..
2013-09-12 23:02:00.447    [DEBUG][4]    SharedMemoryHelper::Open()
2013-09-12 23:02:00.448    [DEBUG][4]    Unable to find in 'Global', about to check 'Local'
2013-09-12 23:02:00.448    [DEBUG][4]    Unable to find in either 'Global' or 'Local'
2013-09-12 23:02:00.448    [DEBUG][4]    RollingFile.Seek(4001)
2013-09-12 23:02:00.449    [DEBUG][4]    about to read 500 from location 4001  (current length = 1912908272)
2013-09-12 23:02:00.449    [DEBUG][4]    RollingFile.Close()

2013-09-12 23:15:06.776    [DEBUG][4]    Got Web Request (192.168.0.99): /live    recording=4880
2013-09-12 23:15:06.776    [DEBUG][4]    StreamNative@1
2013-09-12 23:15:06.776    [DEBUG][4]    StreamNative@2
2013-09-12 23:15:06.776    [DEBUG][4]    StreamNative@3
2013-09-12 23:15:06.776    [DEBUG][4]    StreamNative@4
2013-09-12 23:15:06.778    [DEBUG][4]    RollingFile(D:\ServerFolders\Recorded TV\Double Your House for Half the Money\Double Your House for Half the Money_20130910_21002200.ts)..
2013-09-12 23:15:06.778    [DEBUG][4]    SharedMemoryHelper::Open()
2013-09-12 23:15:06.778    [DEBUG][4]    Unable to find in 'Global', about to check 'Local'
2013-09-12 23:15:06.778    [DEBUG][4]    Unable to find in either 'Global' or 'Local'
2013-09-12 23:15:06.779    [DEBUG][4]    About to stream recording: D:\ServerFolders\Recorded TV\Double Your House for Half the Money\Double Your House for Half the Money_20130910_21002200.ts
2013-09-12 23:15:06.779    [DEBUG][4]    Requested Range: bytes=4001-4500 (499 bytes)
2013-09-12 23:15:06.779    [DEBUG][4]    RollingFile.Seek(4001)
2013-09-12 23:15:06.779    [DEBUG][4]    about to read 499 from location 4001  (current length = 1912908272)
2013-09-12 23:15:06.779    [DEBUG][4]    Sent 499 bytes
2013-09-12 23:15:06.780    [DEBUG][4]    Sent total of 499 bytes
2013-09-12 23:15:06.780    [DEBUG][4]    RollingFile.Close()

I also spent last night playing with the touch web service on my LG TV. I already had the html page and js to interact with LG player from my other project, so it wasn't that hard getting something up and running.
It looks quite promising. Guess I'l start a new thread on that subject.

/Fred