If I somehow can help fix this issue, please poke me! Weird, none of this happens on Mint 17.3 or Debian Jessie. Also, one of the recordings is being detected as a Gzip archive, remuxing it with ffmpeg makes it playable. Tomorrow I will try to delete one of the listed recordings from the HDR and see if another takes its place in VLC.ĮDIT: I've just tried to delete some recordings from the HDR, other recordings are now listed in VLC but again the list is limited to 12 items - seems like a bug to me. It almost seems like the number of files VLC fetches from the HDR is somehow limited to 12. VLC on Kubuntu 18.04.01 only allows me to access parts of the content, I have 5 episodes of a TV-series recorded from the same channel but only one episode is accessible. My HD-recorder is an oldish Panasonic DMR-BCT720 (it stores recordings as raw transport streams, TTS aka MTS, TS etc.), and I have never had any issues with accessing contents from it with VLC on Mint KDE 17.3 and/or Debian Jessie. Reason: Just for the fun of nit-picking, your ffmpeg command is not doing any conversion it is just remuxing streams into a different container Last edited by vidtek December 2nd, 2018 at 09:55 AM.
This is a common cause of many strange network behaviours that non-technical users find puzzling This and the TTL can cause all sorts of weird and wonderful things to happen. So if you disconnect your DNLA server and restart, the old settings may still be floating around in the ether somewhere. I have mine set for 24 hrs, but it can be set for up to a week. One other thing to bear in mind, if you are using DHCP, the router handing out ip addresses will have a time limit that is usually user-settable.
In order to make discovery work correctly you either have to wait up to 20 mins after until the network device has been removed from the network, or switch everything connected off, and I mean EVERYTHING, including the network hub/internet gateway/router/switch/computer/smartphone/tablet. Most network systems have a set TTL (time to live) of 20 minutes (designated in hops). I use kodi on a few raspberry pi systems.DLNA discovery has always been patchy for me. Plus, kodi is pre-configured to point at the DLNA server. The only DLNA player on Ubuntu that seem to always work for me is kodi, but I leave the kodi systems on 24/7/365. I've seen that on all VLC clients with both wifi and wired LAN connections. Even then, it doesn't always seem to work. Because of the way that DLNA announces on the subnet, waiting up to 3 minutes to see all the sources might be necessary. Sometimes DLNA servers show up, sometimes they do not. I've seen the same issue with VLC for years.
0 kommentar(er)
