Experimental TsReader development (3 Viewers)

aalemann

MP Donator
  • Premium Supporter
  • November 19, 2012
    66
    8
    Home Country
    Germany Germany
    v73 works for me too. Seems to be slightly faster, but not sure about that. Thanks for the good work!
     

    mrmojo666

    MP Donator
  • Premium Supporter
  • January 24, 2006
    603
    182
    Turin
    Home Country
    Italy Italy
    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

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    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

    MP Donator
  • Premium Supporter
  • November 30, 2005
    471
    76
    Home Country
    England England
    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;)
     
    Last edited:

    mrmojo666

    MP Donator
  • Premium Supporter
  • January 24, 2006
    603
    182
    Turin
    Home Country
    Italy Italy
    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 :)
     
    Last edited:

    Users who are viewing this thread

    Top Bottom