Advice on which streaming method to use

[fred250]

I'm working on a NPVR client for my LG Smart TV.
My main concern right now is to decide on which streaming method to use.
I've tried a few but no one seem to work all the way.
The most important feature is to be able to seek somewhat accurately in the file. Not necessarily second precision, but say within 15 seconds.

I've experimented using the different options below (and some).

Npvrserver:8866/stream?f=<filename>
- Does a decent job except i doesn't work with all filenames.
Typically filenames including characters åäö (frequenly used in swedish) won't work. (yes, I use url encoding and tried some other character escaping techniques as well)

Npvrserver:8866/live?recording=<oid>
- plays but won't let me seek in file

Npvrserver:8866/public/download.ashx/<oid>,1;
- plays but won't let me seek in file. Also the reported duration time is not correct.

This leaves me with a couple of questions I hope someone knows the answer to.

1: Is there a syntax to use the Npvrserver:8866/stream?-option passing an oid instead of a filename?

2: Is it possibe to retrieve the short filename via NEWA webservices to pass as a parameter and circumvent any local character problem?

3: The filename flaw seems like a bug to me. What are the chances of getting it fixed?

4: Are the any other easy to use, capable of seeking, preferably inbuilt, streaming options worth trying?

/Fred

[mvallevand]

NextPVR dropped official long filename support but I'm not sure accents are permitted in URIs anyway. You could update your recordings database and change the filename field to the shortname.


Martin

[sub]

/stream?f=<filename> and /live?recording=<oid> should give you exactly the same results when it comes to skipping. Stick with the latter. Also has the advantage that you wont have to worry about national charactersets etc.

When it comes skipping, if your TV is not skipping well it probably comes down to how well it's player is handling the unpredictable timelines found in broadcast tv. Unfortunately there is probably not much you can do about it short of remuxing your recordings to ensure they end up with a nice clean timeline.

[fred250]

Thanks sub and Martin for the quick response but of course it raises some new questions.

Official long filename support dropped?
Is it just in the /stream?f<filename> method or in NextPVR in general meaning that new recordings would register with short filenames in the database, and I shouldn’t be facing this problem at all?
A long time ago setting up the PCH I had to set the "use short filename" option to be able to play accented filenames. So NextPVR can apparently present the PCH with short filenames to use. I'm using NEWA web services but have not yet seen any short filenames in data.
If there aren’t any settings I can use, updating the recording database will be a one time job + some postrecording.bat to keep all filenames short?

@sub: So /stream and /live should give exactly the same result? I take your word for it, but they certainly behave different in my environment when it comes to skipping using either the native LG TV player or VLC browser plugin in my desktop chrome.
If you hadn't said they are pretty much the same I would have guessed /live lacks the "range header" capability. I will do some header spying to see if I can spot any difference explaining the different behavior.

In my early experiments to determine if the LG player was at all capable of playing recorded TV with any precision in skipping I just made my recordings catalog available on a webserver and it worked a charm. Both IIS7 and webdev/cassini did a great job seeking in files using the LG player. The only streaming service yet in my tests to measure up with a native webserver is the /stream?f=<filename>.

Mentioned the PCH above. It does a great job letting me skip and even FF/RW in files. Would it be possible to use the same streaming technique in my LG TV project?

Is Touch web services still in development?
Currently my project is a single page html app relying on NEWA web services but I sure like the concept of the touch-web service api introduced in 2.3.6 and wouldn’t mind switching path. Touch web services is a great idea since it offers the native look with all the whistles and bells including plugins with a minimum of work in the client porting it to different platforms.
I’ve not tinkered a lot with it but I have found a few minor issues that probably will need some development in order to be resolved.
Are there any future plans for the touch web service? It’s such a terrific idea now when PCHs are getting harder to find and almost every modern TV has the potential to become a decent client to NextPVR.

/Fred

[mvallevand]

I did mean that NextPVR dropped long file name support to the NMT. Using short names potentially breaks the ability of the client request alternate files that have the same filename but different extension. Notably this would be subtitle files but it could also be the Timing.Info and .edl files that a client might want. However I am sure that it is only a small change to NEWA to present the short names, and you may wish to ask UJB for this feature.

Using the oid also has the disadvantage of not having a library function through an API.

The reason that skipping on the NMT can be accurate is that it will use the Timing.Info mpeg time-based index to skip within ~1 second and not mpeg information. Players that use just the mpeg-ts data will have a terrible time seeking, some player like xbmc uses the ffmpeg mpeg demux directly and will do multiple seeks to get accurate seeking.

Martin

[sub]

Official long filename support dropped?

As Martin said, no, it still records the long file names. This /stream?f<filename> interface was only ever intended to be used by the NMT device, and we used the short file names to work around problems on that environment with national characters etc. Really, it's not worth using that old interface for your project. I'd use the /live one. Its more modern and I'm happy to do make changes in that area to help with your project.

@sub: So /stream and /live should give exactly the same result? I take your word for it, but they certainly behave different in my environment when it comes to skipping using either the native LG TV player or VLC browser plugin in my desktop chrome.
If you hadn't said they are pretty much the same I would have guessed /live lacks the "range header" capability. I will do some header spying to see if I can spot any difference explaining the different behavior.

Yes it does support the range header. Let me know if you have problems getting it working. You should get log messages in web.log saying things like "Requested Range: ...." when it receives these requests.


As Martin mentioned, he was able to get great skipping during TS playback by using the extra timing.info metadata. I'm guessing you don't have the ability to tell the LG player to seek to byte offset, rather than time? You'd need to be able to do that to use timing.info. Otherwise you'll be at the mercy of the TS file timeline and the seeking abilities of the LG player. (as mentioned, manually remuxing recordings can help if this leads to crappy seeking)

In my early experiments to determine if the LG player was at all capable of playing recorded TV with any precision in skipping I just made my recordings catalog available on a webserver and it worked a charm. Both IIS7 and webdev/cassini did a great job seeking in files using the LG player. The only streaming service yet in my tests to measure up with a native webserver is the /stream?f=<filename>.

You might be ok then, and find your broadcaster has pretty good timelines (or HDPVR/Colossus/Analog recordings).

Is Touch web services still in development?
Currently my project is a single page html app relying on NEWA web services but I sure like the concept of the touch-web service api introduced in 2.3.6 and wouldn’t mind switching path. Touch web services is a great idea since it offers the native look with all the whistles and bells including plugins with a minimum of work in the client porting it to different platforms.

To be honest, it was more of an experiment to see if it got any traction with other developers. Unfortunately there didn't seem to be much interest. If you do start using it though, I'm happy to look at further enhancements. Web development is not my area of expertise, so I didn't do too much with it myself.

[fred250]

Wow! I’m impressed to get this much support from you guys. Where do you find the time?

Well…
I suspect my broadcaster does not provide me with any better timelines than others but that the LG TV player has the ability to request a range of bytes, based on it's own calculation considering bitrate and position and not relying on ts-timeline. This would explain why a bog standard resumable-file-download-function of a webserver would do such great job serving the LG TV and also why the (byte oriented?) /stream?f=<filename> made for NMT work so well.

When using the more modern /live, the player recognizes the new features and starts to depend on ts-timeline and skipping gets inaccurate and breaks. Maybe it’s a MIME-issue?

In trying to solve the long filename issue I some time ago tried writing my own range header capable http streamer in c#.net. I can't recall having any problems receiving the long filenames correct (!) but since I couldn’t get the seeking working as accurate as with /stream I’ve put that part of the project on ice.

Anyhow I would prefer using a streaming method that can serve recordings as well as library files.
I guess I'll ask UJB for a short filename option. It seems like the easiest solution for now, unless I can get a fix in the /stream method to accept accented long filenames. Please! Help testing?, no problem


I'm happy to hear you are willing to consider enhancing the touch web service if I start using it. I will continue experimenting and get back to you with suggestions of improvements.
BTW: One of the main issues is that the filename returned by "check activity" is in long format.

/Fred

[mvallevand]

Maybe it’s a MIME-issue?

That's a good possibility, your player may process Content-Type application/octet and video/MP2T quite differently.

Martin

[sub]

That's a possibility. Strange it would do better skipping with application/octet than it would would video/mp2t though.

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

[fred250]

First, I may not have been clear in explaining the issues using /live streaming with the LG player.
Seeking doesn't work at all, it's not that it's inaccurate.

Content-type probably has noting to do with my problems using /live and LG player.
I made some tests using my own streamer and different content-types and there were no indication of such ting.

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