HI
I'm getting somewhere interesting with this and have found a few issues with it. I’ve listed tonights testing as it progresses to give a more accurate audit trail of where things start to go wrong. Although long, I hope this post will assist the development team in checking my results and hopefully addressing any issues they can replicate in the factory. The basic issue is that it appears to start going wrong when used with more than a small-sized FLAC library, which is maybe why it hasn't been detected at the commissioning stages. I wonder if these are exclusive to the ReadyNAS version or more generic? Note tha all these problems are solved by replacing TMS5 by TMS4.4.11 on the same test NAS.
Details of the music library and TMS5 settings
For background, please note that I have spent many weeks retagging all my tracks so they are all to a top standard and show identically on TMS4, SqueezeCenter and Sonos (I have all three systems running from the same FLAC library). The library comprises just fewer than 14,500 FLAC tracks and I've also used Mp3tag (modified with custom fields like albumartist; link on how at bottom of this post) to export all tag info into a CSV and then into MS Access database; I can thus verify referential integrity of my tag formatting and quickly find info to compare with what can be seen on a UPnP control point. All art is in tht form Folder.jpg and comprises 160x160 pixel images (ideal for TMS4). The 14500 FLAC tracks are 1088 albums but all doubles have been combined into a single album to keep the count down due to the TMS4 artwork issues (ie Pink Floyd - The Wall is retagged as a single album with 26 tracks).
In all cases below, the Rescan time has been set to 0 and I’m using the I-Pod view option.
First I pointed the (sharing) path to a few single artist albums only:
With only 22 albums, it now works well in the three basic music tree modes. It also doesn't appear to rescan whenever you restart the server (hard to tell with only 22 albums) so it looks like my theory about the faulty database both causing the problems and initiating rescans might not be too far from the truth!
I then tried 203 albums and it still works but (still in I-Pod mode) shows 'Album' twice in both the TM browser and on the Linn UPnP GUI. On the Linn GUI version with art (Linn Kinsky Desktop) it shows all 203 covers and I think they build slightly quicker compared to TMS4. Again, it's not rebuilding the database upon server restart which is good.
324 Albums and all's well but that's a lot of art to load on the UPnP control point (which is why we like the ABC=1 in the music tree). I think this quantity of art (or more) might cause issues on slower control devices (PDA's, iPhones etc) and thus the ABC=X might be essential for these devices (see TMS4 tree at end for examples of this).
Cidero is now working too. If it's rescanning, Cidero still generates the error I mentioned but it works fine after the TMS has finished the scan. I'll also keep an eye on this as I grow the library.
I then completely changed (sharing) path to now point at compilation albums only:
Having selected a database
rebuild, it now shows the compilations but
hasn't removed the 324 from the original list (they can also still be played) so that's something for support to look at: either it's not forgetting the previous sharing path, or the rebuild isn't deleting what exists in the database; it just adds new stuff. Tried restarting server and then rebuilding but they're all still there.
Frontview test:
Just accessed Frontview OK but when selecting shutdown and restart, nothing happens! The NAS isn't busy scanning (it's just sitting idle) but it's not accepting restart commands from Frontview. Tried downloading the NAS logs From frontview and instead of offering the option to save the log zip-file, the browser now shows a page with the following text: <payload>Empty No Support</payload>
Manual shutdown and restart:
NAS has booted up and TMS is rescanning the database again. Unable to access Twonky home page or Frontview at the moment (but it's still scanning so that's understandible). I've now opened a bottle of beer; hic, belch!
Frontview working again (including logs and shutdown facility) so that's very good! That said, it's started another rescan after the reboot though so that isn't so good. It's finished and I can now access both Frontview and TMS homepage okay. All albums from the deleted sharing path are still there though. Cidero is now working again too!
Changed (sharing) path to now point to all albums on the NAS:
Did above, restarted server and initiated a database rebuild which will take a while. The first five times I installed TMS5, it only showed 3 music tracks (server status) but it's now stopped and is showing 20,648; I've got less than 14,500 so that's incorrect!
Now that it's finished the full 14,500 track scan, I have observed the following issues:
In the Twonky web browser
Under albums, most show no tracks (but a very few do show tracks)
The all tracks list shows a count of 20,648 on the TM web browser but they only go from A~I then stop.
Track count is about 35% higher than reality (tracks duplicated; some shown 3 or 4 times)
On a UPnP GUI
The 'All Tracks' list shows nothing
Some albums cause it to crashes (showing ‘no entry’ message)
On both the web and GUI
Albums are not listed alphabetically
Artists are not listed alphabetically
Often under 'Artist', there are no albums listed (I've 12 Pink floyd albums - none are listed under Pink Floyd)
The Artist/Album selection option has vanished.
Frontview:
Frontview restart and shut down facilities have broken again; NAS has to be restarted using the front switch.
Incidental
Internet radio list is completely missing from web and UPnP controller; I haven't investigated this though.
Conclusion (key issues):
1. With only a few albums, say 300 or so, TMS5 works very well indeed.
2. Changing the share path and rebuilding the database doesn’t remove existing entries
3. Somewhere between 300 and 600 albums and the database rebuilds whenever you restart the server or reboot the NAS.
4. Also at this point, something seems to have impacted on ReadyNAS frontview (maybe the NAS web server interface is being corrupted) but a manual reboot seems to fix it.
5. With the full collection, the database seems to get badly corrupted and TMS web browser shows incorrect info (as well as the links to most of the tracks being broken). The UPnP links to the tracks no longer work (All tracks selection is empty).
6 The track list contains duplicates (sometimes 3 or 4 of the same entry)
7. The album count seems too high (1670 where it should be 1088)
8. The Albums are no longer alphabetically sorted
9. Frontview is misbehaving and a reboot might fix it but the rescan (which starts automatically) breaks it again unless you kill the Twonky process quickly after boot (see 'removal process' below).
Additional points
1. Albumartist tag is urgently required or artist list becomes too big due to compilations (mine's gone from 509 to 5110 which makes it very hard to find artist/album compared to albumartist/album)
2. Music tree ABC=1 requires enabled or selecting ‘Album’ will try to load all art to UPnP control point. (I got it to show 350, I then added more and it only loaded the first 4 with art. This could be the control point which has never been tested in this way)
3. Unlike SqueezeCenter, TMS5 (like TMS4) does not yet recognise the disk spanning tag (disk 1 of 2) that said, maybe it does but has been masked by the other issues. This isn't a major issue and actually helps keep the disk count down in TMS4 (and thus not exceed the 100/container limit for art) but now that the limit has been increased, it would be nice to see this tag picked up in future.
Removal process:
After reboot, TMS5 started to scan again and thus prevents Frontview access. From SSH, I used
ps aux to list the processes and used
kill to stop the PID. I then used Frontview to remove Twonky and it disappeared from the list (and a pop-up message box claimed it had sucessfully been removed) . Again, Frontview's shutdown and reboot command doesn't work. Performed a manual shutdown (with the front switch) and then restarted the NAS. The 'removed' Twonky started rescanning as soon as the NAS had booted up so it's definitely still there and it's also still running!
To remove TMS5, I had to SSH and
kill the PID again, then remove twonkymedia.conf and remove the twonkyvision directory. Frontview restart worked this time (interesting development; maybe it had removed something or maybe just because I killed the process early on) and all is now well again with my NAS.
Incidentally, fantastic to see that TMS5 recognises the Vorbis (FLAC) composer tags; that's a wonderful development, but as you can see from above, there are still a whole bunch of issues needing looked at. I hope this all helps in the development of the product and I'm looking forward to a version which does all 4.4.11 does but with composer tags!
Footnote - Tree requirements:
Attached is the music tree required to deal with large collections (these settings depend on tagging 'albumartist' with the artist for single artist albums as well as assigning compilations an albumartist. Without doing this, you will not see single artist albums under the albumartist tag;
full details on how to tag (and adapt Mp3tag) are shown here. Set as below, this puts TMS4 way ahead of SqueezeCenter and Sonos in that the albumartist list links to whole albums but you can still list all artists under the artist list. With the TMS5 simplified tree, Sonos and SC are way ahead in being able to use albumartist to mask the compilation contributing artists (at the price of seeing the contributing artists).
Note that the music node 8 title 'no art' is specific to TMS4 and the 100 art limit per container; for TMS5 this would be changed change from '3' to '-' to simply list all albums (hopefully TMS5 will stop trying to send art at over a few hundred albums but we need a bit more than TMS4's 100 limit). Also note that I'd remove one of the genre settings and use composer for TMS5.
Bri