Logan007

This -> https://bitbucket.org/stativ/readymedia-transcode <- seems to be based on 1.1.4. Chances are that a diff between 1.1.4 and the bitbucket-transcode topped with some manual adjustements may help to get it applied on 1.2.1.

I am glad that it works for you. Also, thank you for sharing your solution! I have recently discovered an additional alternative way that might be even easier to maintain: n2n (version 2.0 by ntop). It creates network devices and encryptedly tunnels them together to a network; as many as needed; open source and pretty easy to set up; also forwards broadcasts if enabled (-E option) and stable tunnel rebuilt in case of connection losses (-b option if required, for dynamic dns). In my case, it makes...

With a view to uPnP, I unfortunately cannot confirm that Samsung TV behaves any better than VLC. Having VLC in "CTRL + L" list mode and switching to the uPnP pane, a properly announced readymedia server tends to show up about immediately. I nearly don't dare to ask: Did you take a look at the packets' content? Does it show the http://... server location (i.e. address or "localhost"?) in a way that your client will be able to find the server or localhost respectively? I am most interested in your...

Same issue here... I solved it by spoofing a few things in the recorded packets using tcprewrite before having them sent out by tcpreplay on that side of the network where the clients reside. If notes are correct, it must have been something similar to: tcprewrite -C --srcipmap=0.0.0.0/0:n.m.p.q/32 --enet-smac=12:34:56:78:9a:bc --infile=packetsFile --outfile=outPacketsFile Clients might accept the telegrams only if the packets are originating from a computer in their very same subnet; so there was...

Same issue here... I solved it by spoofing a few things in the recorded packets using tcprewrite before having them sent out by tcpreplay on that side of the network where the clients reside. If notes are correct, it must have been something similar to: tcprewrite -C --srcipmap=0.0.0.0/0:n.m.p.q/32 --enet-smac=12:34:56:78:9a:bc --infile=packetsFile --outfile=outPacketsFile Clients might accept the telegrams only if the packets are originating from a computer in their very same subnet; so there was...

Same issue here... I solved it by spoofing a few things in the recorded packets using tcprewrite before having them sent out by tcpreplay on that side of the network where the clients reside. If notes are correct, it must have been something similar to: tcprewrite -C --srcipmap=0.0.0.0/0:n.m.p.q/32 --enet-smac=12:34:56:78:9a:bc --infile=packetsFile --outfile=outPacketsFile Clients might accept the telegrams only if the packets are originating from a computer in their very same subnet; so there was...

I 'm not a developer, either - at least not on this project. Thus, I can't answer your question about plannings on implemetation of certain features. But I agree that this feature would make a wonderful addition... I'm interested in how your testing goes. Please let me know. Maybe, upnp_live would make a feasible alternative for you? Though, I'm not sure if it can handle https. Best regards, Logan

You could try the readymedia-transcode fork (https://bitbucket.org/stativ/readymedia-transcode) and adopt the ffmpeg-transcode script to stream from online sources, e.g. by evaluating the script's filename parameter $1 while having a special file with a predefined name for each stream. Make sure that your TV is capable to play the a/v codecs provided in your online stream (so you just need to copy streams) - otherwise ffmpeg on your dlna-server (you could try remote encoding!) will have to recode...