Experimental TsReader development (4 Viewers)

[Brudertac]

v73 runs fine here. Faster? I think no. But thats no Problem @Owlsroost - Thanks for your hard Work!!!

 

[catavolt]

@Owlsroost: Tested v73 as well - looks very good
THX for your great work from my side, too

 

[aalemann]

v73 works for me too. Seems to be slightly faster, but not sure about that. Thanks for the good work!

 

[HomeY]

@Owlsroost: Tested v73 as well - looks very good
THX for your great work from my side, too

+3!

 

[FreakyJ]

Using this on a singleseat setup since some hours and it is working well so far

 

[Jelmo]

v73 works pretty fine. Thanks

 

[mrmojo666]

with 73 i'm still having choppy live hd tv using rstp on wifi (slight better then before), but using unc is almost perfect.
I don't understand why unc it is working so better than rtsp on wifi.

 

[Owlsroost]

RTSP => lowest network overhead, UDP protocol, so lost packets do not get re-transmitted (when it's gone, it's gone.....), standard live streaming protocol so other clients can connect e.g. VLC

UNC paths => just like any other Windows remote drive, reliable protocol (lost packets are re-transmitted etc), higher network overhead (especially if the network is unreliable e.g WiFi)

Use whichever works best for your system, basically - TsReader.ax doesn't have a preference [DOUBLEPOST=1367519295][/DOUBLEPOST]Thanks for the feedback everyone - looks like I haven't broken anything, and that RTSP is a bit better for some people (which was the idea)

 

[msj33]

RTSP => lowest network overhead, UDP protocol, so lost packets do not get re-transmitted (when it's gone, it's gone.....), standard live streaming protocol so other clients can connect e.g. VLC

UNC paths => just like any other Windows remote drive, reliable protocol (lost packets are re-transmitted etc), higher network overhead (especially if the network is unreliable e.g WiFi)

Use whichever works best for your system, basically - TsReader.ax doesn't have a preference [DOUBLEPOST=1367519295][/DOUBLEPOST]Thanks for the feedback everyone - looks like I haven't broken anything, and that RTSP is a bit better for some people (which was the idea)

Hi Owlsroost - Quick question - Why is UNC not an available advanced option yet, as a secondary straming method? Still under development since its hidden or does it have some disadvantages?

V73 is running all fine here after 10 hours usage

 

[mrmojo666]

RTSP => lowest network overhead, UDP protocol, so lost packets do not get re-transmitted (when it's gone, it's gone.....), standard live streaming protocol so other clients can connect e.g. VLC

UNC paths => just like any other Windows remote drive, reliable protocol (lost packets are re-transmitted etc), higher network overhead (especially if the network is unreliable e.g WiFi)

Use whichever works best for your system, basically - TsReader.ax doesn't have a preference [DOUBLEPOST=1367519295][/DOUBLEPOST]Thanks for the feedback everyone - looks like I haven't broken anything, and that RTSP is a bit better for some people (which was the idea)

maybe this will be a bit ot since it is not related to tsreader, i think

when i use unc: i start a program from a client, after a while from another client i connect to existing tv stream.the result is that i can't go back to the start of the stream on the second client, only on the client that started tv is possible.
for the second client, the start point of the stream seems to be the point of connection.

if i use rtsp, every client that connect to an existing tv stream can go back to the REAL stream start point.

i noticed this behavior from ages (not related to your tsreader development), could you figure out why ?

thank you