@fishfishfish wrote:
I’ve just tried rescanning, but it doesn’t appear to have made any difference, neither does renaming the files. The files are being downloaded by a shellscript directly onto the iTunes server, not via NFS.
As this is 0.2.4, when you rescanned, did you remove the songs.gdb?
I can’t see any obvious differences in the files, but the ones downloaded by the script won’t play in iTunes (despite being picked up by mt-daapd), while others in my music collection will. I can’t see any differences in the permissions or ownership, so I’m baffled as to why they won’t play from the server itself.
They should… it only needs read access, and it must have at least that to have added it into the database.
The only thing I can think is that it grabbed metadata while it was still downloading, and so it got incomplete data in the db.
Can you rename it to somethingelse.mp3? Will that index okay? If so, then that makes me think that it’s related to indexing it while downloading.
If it makes any difference, I’m running mt-daapd 0.2.4 (with the recent iTunes fix) on Debian Sarge for Cobalt MIPS architecture (mipsel-pc-linux-gnu).
If we can’t get it going, might be worth looking at nighlies. 1359 and 1379 are both pretty stable. In fact, 1379 is what’s in debian testing/unstable right now.
— Ron