NASLite-M2 was launched in January 2009 as a media-serving counterpart of NASLite-2. The intention was to provide no-frills UPnP media streaming in addition to the traditional functions of NASLite. The media streaming capability is certainly rudimentary as it's based upon the uShare project (http://ushare.geexbox.org/) which has never claimed to implement all features of UPnP/DLNA. The problematic issue is that the uShare project has been dormant since December 2007 when version 1.1a was released. In addition, the implementation of the uShare code in NASLite-M2 appears to be either incomplete or buggy. I'm unable to stream some flac format audio files from NASLite-M2 to some UPnP/DLNA players, whereas the same files are streamed correctly when running the ushare server application directly from a Linux computer.

I have drawn this matter to Ralph's attention in another thread (viewtopic.php?f=22&t=3913) and also by personal messages (PMs) directly to Ralph. So far, I've not had anything like a full response to my requests and comments in the thread, and the PMs have been ignored entirely.

This leads me to question the viability of NASLite-M2 as a media streaming product. Is there any intention to develop it and replace the uShare component with a better streaming engine? I've done some testing of miniDLNA (http://sourceforge.net/projects/minidlna/) over the last week or so and it's much superior in many ways. Unlike NASLite-M2 and uShare, it correctly indexes and streams the tags content of audio files, allowing players to display the data correctly and build menus based on these data.

The simplest solution for me looks like buying a Netgear ReadyNAS Duo V2 for £100 and moving a couple of disks into it from my NASLite-M2 machine. miniDLNA is the media streaming software installed on the ReadyNAS. It's maintained by Netgear and released as open source to the public.

The alternative solution would be for Ralph and Tony to commit to a major update to NASLite-M2 by replacing uShare with miniDLNA within a reasonable time frame.

I've been a fan of NASLite for more than six years, but it may now be time to jump ship.

I believe that development for NASLite has stopped. I have sent mails to the developer about other features that he said would be available last year in fall. All follow up mails have met a dead end, no replies.

NASLite-M2 was launched in January 2009 as a media-serving counterpart of NASLite-2. The intention was to provide no-frills UPnP media streaming in addition to the traditional functions of NASLite. The media streaming capability is certainly rudimentary as it's based upon the uShare project (http://ushare.geexbox.org/) which has never claimed to implement all features of UPnP/DLNA. The problematic issue is that the uShare project has been dormant since December 2007 when version 1.1a was released. In addition, the implementation of the uShare code in NASLite-M2 appears to be either incomplete or buggy. I'm unable to stream some flac format audio files from NASLite-M2 to some UPnP/DLNA players, whereas the same files are streamed correctly when running the ushare server application directly from a Linux computer.

The above is a fairly accurate representation with a few exceptions. The uShare binary can be compiled without a dependency on libdlna in which case what you'll get is a sleek, light-weight daemon that can export ANY file via UPnP. The burden is then on the client to do what it can with the exported file. The problem however is that there is no file format metadata supplied to the client since uShare has no facilities to determine file type/format other than via extension.

Although extremely versatile, the lack of metadata was insufficient in satisfying the requirements of embedded UPnP clients such as Playstation or music players. So, we implement DLNA support using libdlna and it's ffmped dependencies. The total weight of uShare went from 40K to well over 2M. The side effect of that move was formats that are not defined by the DLNA standard and/or not supported by libdlna are potentially crippled or not visible at all.

The flac format, is most certainly not a DLNA mainstay. Most DLNA embedded devices that would even touch it, can not do so by streaming, and require USB connected storage so the flac files are locally visible.

That said, the capabilities of NASlite are not infinite and should not be compared to what Windows7 or Ubuntu can do for you. NASlite-M2, just like it's siblings, is an embedded OS that focuses on stability, performance and ease of use. Abundance of features will always counter any one of those.

Lastly, Server Elements continues it's development duties as always and will offer future releases of it's current and new products.

The uShare binary can be compiled without a dependency on libdlna in which case what you'll get is a sleek, light-weight daemon that can export ANY file via UPnP.

Quote:

Although extremely versatile, the lack of metadata was insufficient in satisfying the requirements of embedded UPnP clients such as Playstation or music players. So, we implement DLNA support using libdlna and it's ffmped dependencies. The total weight of uShare went from 40K to well over 2M. The side effect of that move was formats that are not defined by the DLNA standard and/or not supported by libdlna are potentially crippled or not visible at all.

Tony's reply seems to say that the decision was taken to create more than just a bare-bones streaming daemon in spite of the fact that inclusion of libdlna and ffmped [ffmpeg?] added significantly to the footprint of NASLite-M2. However, having read and re-read Tony's response, I still remain confused about why the standalone version of uShare (running on Linux Mint) streams every file that I throw at it, but NASLite-M2 streams some files and not others. The code base with respect to the two ought to be the same.

Quote:

As Tony pointed out, and from our discussions on this, Flac is not a supported media format for the DLNA spec, DLNA.org provides the tech specs on the supported formats.

Ralph is entirely correct about Flac not being an audio format which is supported by DLNA, so the fact that NASLite-M2 can stream some Flac files must be seen as a bonus. However, it would be nice if NASLite-M2 could match the streaming capability of uShare, on which it is based.

The remaining issue which has not been addressed is miniDLNA. This is an actively supported project and it provides streaming of metadata too. I can understand the design philosophy of NASLite with respect to keeping the code footprint small and efficient, but surely those who purchase NASLite-M2 do so for its media streaming ability as well as it providing traditional NAS. I suspect that many would welcome improvements in the media streaming ability of NASLite-M2 even if the footprint was further increased.

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.

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.

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.

Let's not get confused here Ralph. The link which you provided was to an announcement for minidlna-transcode which is described as a branch (fork?) of the original minidlna project. Minidlna is maintained by Justin Maggard (sitename jmaggard) who works for Netgear. This branch project is maintained by somebody else (sitename stativ) whose real name is Lukas Jirkovsky (https://bitbucket.org/stativ/minidlna-transcode).

The purpose of minidlna-transcode is to transcode media to allow them to be played on players which cannot render some media types natively. The original minidlna media server does NOT transcode any media files and I have no need for it to do so because both of my media players natively support the media which I wish to stream to them.

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.

I also have been a client of Server Elements for years. (I forgot my login to the forum so I had to re-register tonight). I also have been looking to leave Naslite only... ONLY for the DNLA issues with Naslite.

Naslite has been stable... totally stable for years.. often up for months on end.. until we get a power outage.

l also thought that no new developments were coming for NASLITE. Their have been no new announcements of future products... so i thought it was what it was and that was it...

The issue for me is that DNLA is. not providing what my appliances are looking for.. Can you give us an update on if there will be any improvements to the DNLA support?

I just noticed this exact issue and frankly find it ridiculous that, in order to watch a "new" video (recently placed on the M2 server) on my PS3, I have to log into the M2's CLI, go through a menu, and "refresh" it (Services Configuration / DAAP/UPNP Options / UPNP Reindex Content).

It looks like it's been 2 years since requests to address this were mentioned in this thread (either a scheduled refresh or an easier refresh through the Web UI), but it doesn't seem to have been addressed yet (let me know if that's not true).

As it stands now, my update to M2 was a waste of time and money. The manual refresh procedure is completely impractical.

As it stands now, my update to M2 was a waste of time and money. The manual refresh procedure is completely impractical.

I'm perfectly happy with the current system, I have over 50K music files, that alone takes 40 minutes to index, let alone movies etc, like I want the system unavailable all the time to refresh content that hasnt changed.

So what automate it every hour, so I get 10 minutes every hour to use it, LOL now thats impractical.

There are two separate issues raised by svensk and by MotorCityKid but both are pertinent to how NASLite-M2 might be developed. In many ways, svensk feels as I do that the DLNA functionality of NASLite-M2 is not providing what his appliances (renderers) are looking for. In addition he asks for a method to refresh the index without going through the CLI. I would agree with that sentiment but polling the server on a regular basis for new content is not an ideal solution as MotorCityKid points out because of the size of his media collection and the time which it would take to re-index.

I would imagine also that the NASLite-M2 start-up time for MotorCityKid is lengthy given the size of his media collection and the fact that the index is held in memory, rather than written to an index file. That's why there is no need to save the configuration when you re-index the media content. I would imagine that the index size could be substantial in some cases and it's probably just as well that only file names are indexed rather than all of the metadata embedded in tags in the media files.

There is the potential for both issues to be addressed by replacing the uShare DLNA server in NASLite-M2 with miniDLNA.

Apologies if I have made any unwarranted assumptions about the genders of svensk or MotorCityKid.

You know that it is very easy for us to sit back and make requests for changes to the package without realizing the sometimes massive work that those seemingly simple changes might entail. What may seem a simple change to the underlying DLNA package might have dire effects requiring that large swaths of code be reworked and put to the test. I have more than a few changes I would like to see happen in the future but I also realize that what I want may not jive with the overall functionality and broadest support motive and most important data security for the package.I would suggest that there are other options out there that may better fit your needs than NL for your particular situation. One is to simply roll your own.

I presently use PCs, Macs, iPads, iPhones, and Android devices to play both videos and music files off of my NASLite box. I have started using XBMC and it seems to do a great job of indexing most all file types. This means that I simply need a NAS with no other functions to get what I need. In this I have no complaints at all and would suggest that you look at it as one possible option. The interface (confluence) is clean and easy to navigate and the package plays everything I have thrown at it so far. It is open source and is ported to just about every OS. For those targets that there is not a packaged download you can get the source and compile one.

Last, Tony and Ralph are just two guys that when they started were rolling what they needed for personal use and figured that they could not only help others but maybe turn a little extra green for the effort as well. They, like you and I, have lives and jobs and families that take priority over our desires. Software, like life, is very seldom perfect and though frustrating we live with it, we find, or we create an alternative we can live with.

Who is online

Users browsing this forum: No registered users and 7 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum