I'm using the QNAP HS-251 and Asset 4.3. Since the Qnap firmware update to 4.4.2 (12/31/2014) the Asset UPnP cannot scan and list my music folder \share\Multimedia\. I try to uninstall and reinstall and make a clean new install of the current beta of Asset 4.4. The Internet Radio works fine.
Cound anyone help - or is this a bug at the moment - so I'll wait some days.
I enabled the library log and all files were scannt, but for each file there is an error "Error cannot read track meta, file must be in use.". I've set the directory as read only. It's the same permission ever. If I use the QNAP File Station, I can access to all music files and playback them. The same way with a Windows computer.
thank you for this hint. I set the permissons again (777 and 775) owner 0 - all recursiv, but there is the same error message. Then I copied some music files to a new created directory with guest full access permissions and edit the media folder path in Asset - the same error.
So I install a Logitech Squeezebox Server on a Raspberry Pi and mount the music files as a NFS share - this works fine.
uninstalled and reinstalled Asset. Here are the entries of the logs:
22:19:20 Scanning Library...Counting Audio Tracks
Database op took 1598 ms
Field Match Check, Did not match - dropping database
Database op took 0 ms
Database op took 0 ms
...
Database op took 0 ms
Creating New Database
Database op took 963 ms
Database op took 326 ms
4266 Tracks Detected, Checking for Missing/Changes
22:19:38 Adding New Track: /share/Multimedia/musik/musik_flac/Aimee Mann/Bachelor No. 2 or, the Last Remains of the Dodo/12 Save Me.flac
Error cannot read track meta, file must be in use.
yes. The behavior in 4.3 and 4.4beta is the same. I also tried the Qnap internal Twonky server. Twonky detects the files.
Conclusion of my tests:
- since the Qnap firmware update from 12/31/2014 the Asset 4.3 notice the music files, but cannot track meta data
- reinstall 4.3 doesn't solve this issue
- Asset 4.4beta doesn't solve this issue
- Internet radio runs fine over UPnP
- setting new permissions (775 / owner 0) doesn't solve this issue
- internal DLNA servers like LMS 7.7.2 and twonky 5 can index all music files and deploy
- external DLNA servers like LMS 7.8.2 on Raspberry PI can mount the directory as NFS share and index the music files
- XBMC on Raspberry PI connected via NFS and/or SMB and play the music files
- The internal Qnap Audio player plays the music
Thanks for the detailed report. Sounds like some kind of a bug is preventing the metadata from being indexed, certainly not a premission issue.
Does anybody else get this bug? Or does anybody else using the same QNAP model *not* get this bug?
We'll get to the bottom of this by including more debug information in the debug logs in upcoming Asset beta releases. As a workaround you could probably use the Raspberry Pi version of Asset instead.
[tag read log] ->-> [Open]
[tag read log] Opening file '/share/Multimedia/musik/musik_mp3/Daft Punk/Discovery/08 High Life.mp3' for read access: *** Error: Error opening file '/share/Multimedia/musik/musik_mp3/Daft Punk/Discovery/08 High Life.mp3'check no other program has it open. [Open]
[tag read log] dBDecoder.Open failed
Could not read track meta, please check file permissions on: /share/Multimedia/musik/musik_mp3/Daft Punk/Discovery/14 Too Long.mp3
[tag read log] ->-> [Open]
[tag read log] Opening file '/share/Multimedia/musik/musik_mp3/Daft Punk/Discovery/14 Too Long.mp3' for read access: *** Error: Error opening file '/share/Multimedia/musik/musik_mp3/Daft Punk/Discovery/14 Too Long.mp3'check no other program has it open. [Open]
[tag read log] dBDecoder.Open failed
Database op took 0 ms
Scan Finished: 19807 ms
Library Contains 0 Tracks, 0 Albums, 0 Pictures
Attached you find the config-dump.
The permissions are the same as before and for the directory "/share/Multimedia/musik" are 775 owner 0.