2013-09-21, 02:25 PM
@reven
Happy to hear you got it working!
Yes, jumping about 70 mins forward at first go seemed a little odd, now I got the explanation.
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.
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.
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.
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
Happy to hear you got it working!
reven Wrote: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.
reven Wrote: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.
reven Wrote: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.
reven Wrote: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.
reven Wrote: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