Quote:
You keep claiming uShare is deficient. UpNp servers simply scan media files and index the meta data, and present it to the users uPnP renderer via http/xml.
If the renderer wont play them, the renderer is deficient.
My claim is that the implementation of the uShare code in NASLite-M2 is deficient,
not that uShare itself is deficient. I can stream flac-encoded files using the uShare server application from a PC running Linux Mint and play them successfully on both of my two DLNA media renderers. The exact same flac-encoded files when served from NASLite-M2 play on one of these media renderers, but not the other. So, I have one media renderer which plays flac-encoded files streamed from uShare but not from NASLite-M2. Since the flac-encoded audio files and the media renderer are common to the tests, I have to conclude that the two servers (uShare and NASLite-M2) are not fully equivalent in a functional sense. I have tested each of the three DLNA profiles provide by NASALite-M2 and I encounter the same behaviour with each. I thought that I had made these points previously, but perhaps that was in another thread. Apologies if my previous description of the problem was unclear. I hope that it is clear now.
The major deficiency with uShare is that the only metadata which are provided to the renderer are the names of the files. Data such as artist name, genre, album name,
etc. are not served to the renderer. As far as I know, such data are not indexed at all by uShare.
Quote:
Here's an example. Windows Media player see's my flac test files under M2 using the generic profile. When I click on them, Media Player attempts to start to play, then presents me with an error saying it doesn't have the required codec. Since Windows and OS X *dont't* support flac out the box, I installed a flac codec. Windows Media Player still won't play the flacs. I installed MediaMonkey, MM plays the flacs.
This is perfect example of the inconsistency with the DLNA standard, the burden is on the renderer.
That's my experience too and exactly what I would expect.
Quote:
And we haven't even gotten to badly encoded media files, for example, some mp4 video encoders put the meta data at the end of the movie file. That causes all sorts of performance problems when you need to seek to the end of 4g file to get the meta data, most of the renderers simply time out on those. The PS3 is perfect example of this.
I have encountered this issue too with flac files, so no surprises there either. The vast majority of the flac files which I wish to stream are rips of my CD collection. I have investigated several methods for ripping CDs to flac files and have found that Exact Audio Copy (
http://www.exactaudiocopy.de/) which uses the official flac encoder (
http://flac.sourceforge.net/) produces the most reliable results. None of the commercial flac files which I have purchased have ever proved problematic when attempting to play them.
All DLNA media renderers will have their own peculiarities and quirks. The two which I use have their differences just as I have descibed above. However, I believe that I have shown that NASLite-M2 and uShare themselves have quirks and differences. The key point is that NASLite-M2 and uShare behave differently as servers even though the former is based on the code of the latter. The goal, surely, is to identify the basis of that difference.
As I have said previously, I would more than happy to be a beta tester if you were to decide to try to make the media streaming component in NASLite-M2 fully equivalent to uShare. However, in an ideal world, I'd like to see NASLite-M2 updated to embrace a more full-featured DLNA server which supports all metadata, such miniDLNA.
Thank you.