Time to make Touch web Service less experimental

[fred250]

@reven
Happy to hear you got it working!

well i had a very foolish error, my milliseconds were getting converted to a string at some point, so when i was adding currentmilliseconds + jump it was concating which was making it jump to the very end of the file.

Yes, jumping about 70 mins forward at first go seemed a little odd, now I got the explanation.

once I fixed that, currently I can jump correctly for the most part, but the first jump is always wrong (goes to the first jump as the default npvr streamer, one file is 2mins another is 4:30).

Yes that is a bug I've noticed to. One other thing I might tell you is that any seek position less than 10 000 (<10 secs into the file) will be ignored. Probably not related to the bug but anyways.

also i cant jump past the point the npvr streamer reported was the duration to the samsung player.

I don't know if your Samsung player gets the duration time from the ts-timeline or calculates it from the reported number of bytes (which seems odd) but would explain why the reported duration changed when you switched to my streamer.
If not requesting a specific range but rather the whole file starting at a certain position the actual file size is always reported as the end byte.

Now that you have the source code and are able to run in debug mode you''ll see that both request and response headers are logged.

Going to look into those 2 issues, but this is looking very promising, the other jumps are pretty accurate, within a second or two (sometimes spot on).

Yes, Timing.info has a precision of 850 ms I think, and the way I implemented it gives the streamer 2x850ms = less than 1.7 s precision and then the player need some time to get things in order.
I haven’t bothered trimming that part but I think it's possible to get close to 1 sec accuracy.

If we can get this to work, I'm hoping sub can implement this directly into nextpvr, so no other app/port is required for streaming, perhaps a different url however eg ?tsstream=

great work fred

Yes I hope so too. The streaming needs to be sorted now that we see all sorts of clients coming.
I made this streamer as an experiment only because I can't get the inbuilt /stream or /live streaming options to work with my LG TV for different reasons.

/Fred

[mvallevand]

Yes I hope so too. The streaming needs to be sorted now that we see all sorts of clients coming.
I made this streamer as an experiment only because I can't get the inbuilt /stream or /live streaming options to work with my LG TV for different reasons.

If it doesn't fit with sub's plans, you should be able to integrate it with NEWA if it is C# and it is quite easy to integrate. This would help while you are experimenting and making changes anyway.

Martin

[fred250]

If it doesn't fit with sub's plans, you should be able to integrate it with NEWA if it is C# and it is quite easy to integrate. This would help while you are experimenting and making changes anyway.

Martin

Yes it's basically a few routes and request handlers all C# and .NET4.0 so that seems to be an option.

I had an idea of using your writeTime tool from inside the streamer to generate Timing.Info if not provided. This way by the time the user wants to skip the first commercial the timing.info is there to use.

/Fred

[reven]

true NEWA would be an appropriate backup solution as thats bundled with nextpvr anyway.

My bug isnt related to the 10second ignore if statement, trying to jump 60 seconds.

I thought it might be that the "Content-Range" response header is written before it recalculates "getTimeInfoCorrectedStartByte", so I made it do that before written the header. No joy. still doesnt do the first jump correctly. I was hoping I could force the player to play a specific byte range (basically telling it to shut up and takes these bytes )

The first jump seems to do a very odd request

REQUEST INFORMATION (GET)
Connection: close
Accept: */*
Host: redhood
Range: bytes=984191092-
User-Agent: Lavf52.104.0

which is really quite far into the file, around 30 minutes. although after it jumps its playing at 4:07 (which is about 117089408 bytes).


If I jump back in the file, even to 0seconds, i can then correctly jump 60 seconds. Just the very first jump.

3am here, going to give up for the night.

[fred250]

true NEWA would be an appropriate backup solution as thats bundled with nextpvr anyway.

My bug isnt related to the 10second ignore if statement, trying to jump 60 seconds.

I thought it might be that the "Content-Range" response header is written before it recalculates "getTimeInfoCorrectedStartByte", so I made it do that before written the header. No joy. still doesnt do the first jump correctly. I was hoping I could force the player to play a specific byte range (basically telling it to shut up and takes these bytes )

The first jump seems to do a very odd request

which is really quite far into the file, around 30 minutes. although after it jumps its playing at 4:07 (which is about 117089408 bytes).


If I jump back in the file, even to 0seconds, i can then correctly jump 60 seconds. Just the very first jump.

3am here, going to give up for the night.

Thanks for giving me the feed back. Since I also experience the same first skipping error it shouldn’t be that hard to track down.

Sleep well!

/Fred

[fred250]

I thought it might be that the "Content-Range" response header is written before it recalculates "getTimeInfoCorrectedStartByte", so I made it do that before written the header. No joy. still doesnt do the first jump correctly. I was hoping I could force the player to play a specific byte range (basically telling it to shut up and takes these bytes )

Forgot to tell you. I never rewrite the headers based on the seek parameter. I let the player think it made the correct byte request. I just return the part of the file that it is really expecting in terms of time.
It's a sort of "do what I mean not what I say" streamer.

/Fred

[sub]

Yes, I'd be able to implement something like this.

[fred250]

Yes, I'd be able to implement something like this.

Thanks sub,
That's good news!

/Fred

[UncleJohnsBand]

I need to understand more about what this is...... there is no reason it couldn't be a "plugin" for NEWA meaning the code, packaging and support is outside of the normal packaging/distribution/support process.

Not to say I think this is a bad idea or anything....but NEWA already supports the native NPVR streaming as well as VLC based streaming.

I am not sure adding a 3rd streaming solution as standard delivery with NEWA is necessary.

What would this new streaming be used for?

Who would use it?

What is it's purpose in life?

[sub]

I wouldn't be adding any new streaming method. I'd just be a slight modification to the existing streaming code, so that the client can give the server a hint about where it wants to skip to. If it got one of these hints, then it'd ignore the byte range the player requests, and instead it'd use a byte offset looked up on the server from the timing.info.

For example, client process could give the server a hint saying "the player is about to skip to 345 seconds". When the new request arrives from the player shortly after, the server would ignore the requested byte range, and instead start delivering the data from where it thinks 345 seconds into the file is.