Time to make Touch web Service less experimental

[sub]

Sub, what does nextpvr do when one plays a in progress recording? does it change those values as the file size changes?

You mean via http? It'll return the file size in the http response header, as it is when the request is made. Some players will request additional chunks from the server from time to time to check if the length has grown, and will honor the new length. Most players wont though - like XBMC, which just stops playback when it reaches the original length at the time it started playback. ie, I don't have any magic that forces players to keep playing beyond where it thinks the file finishes.

[reven]

true, trying to figure out why dynamically changing the content length isnt working.

the way my samsung tv works (and probably most/all players) is when you skip forward/backward the current connection is closed and a new one is opened with the jumped byte range. however when I alter the content-length and increase the end bytes in range headers, the player still doesn't let me jump past the actual end bytes. which I think it should... since the samsung tv now thinks the end is say 1300mb.

im thinking there must be something else preventing it in the tsstreamer, as the player should just think the file is larger and continue to play.

I suppose another work around would be to stop playback on jump and then start playback again but by passing in startpos, then just handle the timeline myself. as thats what its effectively doing, stopping the connection and creating a new one, there shouldnt be any difference in skipping speeds.

[fred250]

im thinking there must be something else preventing it in the tsstreamer, as the player should just think the file is larger and continue to play.

This doesn’t sound like your problem but I'd better tell you.
I had a timing problem where the newly set seek value just wasn't visible to the streamer yet. The effect I got was that it jumped to the prior value. It was easily solved by making sure enough time elapses.

I suppose another work around would be to stop playback on jump and then start playback again but by passing in startpos, then just handle the timeline myself. as thats what its effectively doing, stopping the connection and creating a new one, there shouldnt be any difference in skipping speeds.

This should work I guess.
Is it just this one file or are you experiencing the same with more files or all files?

You probably described the phenomena in detail but I didn’t catch all the details.
When you start playing a file the Samsung player reports a certain duration time – is this one correct or incorrect?

After a seek has the reported duration time changed?

Have you noticed any effects of the experimenting with headers?


Some ideas to try:
You may try changing content-type to something like video/MP2T, video/vnd.dlna.mpeg-tts or video/mpeg probably no effect but the player may treat the types differently.

In the parameters to the media object for my LG there is something called “oneshot_url” which causes the player not to do a lot of small range request at the beginning. Have you had a look at the options for your player, if there are any?


/Fred

[reven]

This doesn’t sound like your problem but I'd better tell you.
I had a timing problem where the newly set seek value just wasn't visible to the streamer yet. The effect I got was that it jumped to the prior value. It was easily solved by making sure enough time elapses.

if you're referring to the the 10sec if statement, then no that wont be the issue. it happens around the 11 minute mark trying to jump 60 seconds. This is the point where the request is asking for a byte range outside of the actual filesize (even happens when I alter the headers with a new fake filesize)

This should work I guess.
Is it just this one file or are you experiencing the same with more files or all files?

yeah happening with the two sample files I have.

You probably described the phenomena in detail but I didn’t catch all the details.
When you start playing a file the Samsung player reports a certain duration time – is this one correct or incorrect?

After a seek has the reported duration time changed?

I havent actually checked this, my code might only set the duration on the first request, Ill see if this changes tonight

Have you noticed any effects of the experimenting with headers?

only thing I've found is sometimes I break it more Ive had no success yet as to make the duration grow in the player past the point where it thinks the file ends. Ill play to see if it can just continue to watch past the point the file ends too (ive only tested jumping past it).

Some ideas to try:
You may try changing content-type to something like video/MP2T, video/vnd.dlna.mpeg-tts or video/mpeg probably no effect but the player may treat the types differently.

In the parameters to the media object for my LG there is something called “oneshot_url” which causes the player not to do a lot of small range request at the beginning. Have you had a look at the options for your player, if there are any?


/Fred

havent tried changing content type yet, and no clue if theres a oneshot_url or anything (could look into that), also Ill investigate if the player is making a small request at the beginning to get the file size which maybe the case. In that event, I could try looking for this request and just return the end 100 larger. Just have to test if response.end will actually gracefully exit the player. Come to think it, this might be the cause...

I'm sure theres a way around this, just have to figure it out. Understand a lot more to whats going on now, and really isn't all that complicated once you get your head around it

[fred250]

if you're referring to the the 10sec if statement, then no that wont be the issue. it happens around the 11 minute mark trying to jump 60 seconds. This is the point where the request is asking for a byte range outside of the actual filesize (even happens when I alter the headers with a new fake filesize)

Nope, a new issue I faced when I reworked the client code. This one is all about client code and timing.

yeah happening with the two sample files I have.

Meaning that most files are ok then?

havent tried changing content type yet, and no clue if theres a oneshot_url or anything (could look into that), also Ill investigate if the player is making a small request at the beginning to get the file size which maybe the case. In that event, I could try looking for this request and just return the end 100 larger.

You can't be sure with these things but it seems unlikely that only changing your header in response to the initial request to pretend the file is larger is suddenly gonna let you seek beyond the duration time (this is sort of what you have been trying for a while isn't it). I'd guess changing it later while writing the response chunks, hinting the player that the file grows and that it's known duration time is noting to hold on to, would seem a little bit more likely.
I now highly suspect your duration time comes from ts-time line. If you can spot the request that seek to near the end of the file to find the last timetick, try returning bytes from a bit earlier in the file. This should give you a shorter duration time.
If that's the case and you can't find an option in the player to fix this we need some really hard persuasion methods.

I'm thinking:
Get a rather long file that is behaving nice and always returns the correct time through the whole file. It may be specially made for this purpose.
When the player makes it's initial request to determine duration time just return the corresponding bytes from the nice file (looked up comparing the two Timing.Infos). - And Bob's your uncle.
I don't know if it will work but it's worth a try anyway.

Just have to test if response.end will actually gracefully exit the player. Come to think it, this might be the cause...

Well most of the time the streaming ends by the client disconnecting. Gracefully or not by leaving an client lost exception in the streamer. Shouldn’t be a problem I guess.

I'm sure theres a way around this, just have to figure it out. Understand a lot more to whats going on now, and really isn't all that complicated once you get your head around it

I think it's complicated enough having to deal with black boxes of players. At least my LG states it's a GStreamer-something in the user-agent. That info might be useful some day.

/Fred

[fred250]

if you're referring to the the 10sec if statement, then no that wont be the issue. it happens around the 11 minute mark trying to jump 60 seconds. This is the point where the request is asking for a byte range outside of the actual filesize (even happens when I alter the headers with a new fake filesize)

The player is asking for a byte range outside of the actual filezsize? - that’s odd. Well the streamer can't return those bytes anyway(!?) I'm not quite sure what happens beside I know a range request beyond filesize will be limited to the last byte of the file.

However if timing.info is present the streamer should be able to return the correct bytes and playing continue at the correct position in terms of time.
Maybe I can download the file to see if it behaves the same way with my LG.

/Fred

[reven]

i mean the player is requesting a byte range outside the file size, because for example, the player requests byte 500 out of 1000, but the actual time it wants is at byte 300, so the tsstreamer returns byte 300. Meaning there are 700 bytes left, but the player thinks there is only 500 bytes left. so when it tries to jump to actual byte 900, the player is actually requesting byte 1100, which is greater than the 1000. the 1100 would get translated to 900 on the server. and the player will stop at byte 800, leaving out the remaining 200 bytes.

[mvallevand]

Well most of the time the streaming ends by the client disconnecting. Gracefully or not by leaving an client lost exception in the streamer. Shouldn’t be a problem I guess.

The seeks on the NMT are all new sockets and the old ones are closed without cleanly shutting down and this hasn't caused any problems except for a few users that see this logged as an error in web.log

Martin

[reven]

well i found the problem

Code:

long bytesToReadRemaining = (this.EndRangeBytes[i] - this.StartRangeBytes[i]) + 1;

was using the requested, unaltered start/end bytes which would give a negative value for bytes remaining and the tsstreamer would close the connection (not the samsung player)

changing it to

Code:

long bytesToReadRemaining = this.InternalRequestedFileInfo.Length - startpos + 1;

I can now jump to about minute 31 out of 34, im sure there is another tiny bug I can fix to jump the entire way. Also I don't have to handle the timeline myself or anything, and it mostly just now works (all that is required on my player is im passing in an additional &guid parameter to the video player and I call a seek request before jumping)

So, what I'm doing is.
# For a file with 1000 bytes (just an example )
# For the initial stream request i respond with Content-Range: bytes 0-1000/1000 and Content-Length: 1000
# When a request comes in, I alter the requested start byte with the adjusted byte eg, change 500 to 300
# I respond with Content-Range: bytes 500-1200/1200 and Content-Length: 1200
# I then just adjust the start range to and respond with bytes 300 to 1000, the player thinks its bytes 500 to 1200

And I can now successfully watch the entire faulty videos provided by stustunz and smacrae.

so Fred, well done you have solved the problem I've been having with the samsung player, just need to polish it up and hopefully get sub to add it or to get it into NEWA.

This will make smacrae very happy

[fred250]

i mean the player is requesting a byte range outside the file size, because for example, the player requests byte 500 out of 1000, but the actual time it wants is at byte 300, so the tsstreamer returns byte 300. Meaning there are 700 bytes left, but the player thinks there is only 500 bytes left. so when it tries to jump to actual byte 900, the player is actually requesting byte 1100, which is greater than the 1000. the 1100 would get translated to 900 on the server. and the player will stop at byte 800, leaving out the remaining 200 bytes.

Alright I see, so the problem seems to be the fact that the streamer ends streaming before the file ends, or the player closes the connection when it thinks all bytes have been received.

I’m not having files that are that “broken”. Usually a skip without the help of timing.info is less than a minute or so off with my files, so I haven't really experienced your problem.

Have you tried to totally ignore the requested byte range and response with the correct headers and bytes starting with what you get from timing.Info just as the response would have been if the timeline was ok and the player were able to request the right range.
It may confuse the player though not getting the requested bytes in the header.

One option might be to add the difference between requested and corrected start byte to “remainingBytesToRead” so that it won’t stop the streaming before the file ends, if that’s the problem.

Also I still left the initial seekToPostition = 0 statement and the first seek still works. I think in my case that was related to my timing problem in setting the seekToPosition from the client.

I’d be interested in looking into this problem first hand. Can I obtain a copy of one of the files?

/Fred