Zero track length permissions issue

[fishfishfish]

I’ve been running mt-daapd on a Debian-based Raq server for the past year or more and it’s worked excellently.

I’ve recently installed a script which downloads podcast mp3s. These are picked up correctly by mt-daapd but have a zero track length in iTunes and won’t play. I’ve added a function to my shellscript to chmod the files to 777 so they can be read, written and executed, but they still won’t play.

This is ls -la for one of the tracks that won’t play:

-rwxrwxrwx 1 matt matt 1945600 2006-11-04 01:35 podcast.mp3

This is one of the tracks that will play
-rwxrwxrwx 1 matt matt 7568390 2005-10-13 04:14 workingpodcast.mp3

Any ideas what I need to do in order to get them to play from iTunes, please? The files work correctly when they’re download to my Mac, so I’m fairly sure it’s something to do with permissions/ownership…

Many thanks,
Matt

[rpedde]

@fishfishfish wrote:

I’ve been running mt-daapd on a Debian-based Raq server for the past year or more and it’s worked excellently.

I’ve recently installed a script which downloads podcast mp3s. These are picked up correctly by mt-daapd but have a zero track length in iTunes and won’t play. I’ve added a function to my shellscript to chmod the files to 777 so they can be read, written and executed, but they still won’t play.

This is ls -la for one of the tracks that won’t play:

-rwxrwxrwx 1 matt matt 1945600 2006-11-04 01:35 podcast.mp3

This is one of the tracks that will play
-rwxrwxrwx 1 matt matt 7568390 2005-10-13 04:14 workingpodcast.mp3

Any ideas what I need to do in order to get them to play from iTunes, please? The files work correctly when they’re download to my Mac, so I’m fairly sure it’s something to do with permissions/ownership…

Many thanks,
Matt

If you do a full scan from the web interface, do they work? Are those files nfs mounted, or are they on the same system as the server?

One “trick” that might be worthwhile (assuming the full scan picks them up), would be to dump the files with a temporary name (podcast.mp3.part) and then rename them at the end of the script.

[fishfishfish]

Thanks for your help, Ron. (And thanks for the excellent software! I’m a big fan and have introduced several of my friends to it).

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.

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.

Do you know if iTunes/daap is fussy about file permissions or ownership in some way?

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).

Many thanks again,
Matt

[rpedde]

@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

[fishfishfish]

Thanks for the troubleshooting help, Ron.

I’ve deleted songs.gdb, rescanned and restarted but it’s still not playing the tracks, or determining their length in iTunes.

I’m fairly sure now it has something to do with the actual files themselves, and is not an issue with their metadata being added before the tracks had fully downloaded.

I just installed the downloading script on my Linux box and transferred the files to my Mac, where they play normally in iTunes. They also play correctly on Linux. As soon as they’re added to my iTunes server (after indexing) iTunes cannot play them and doesn’t display their track length.

Any ideas what might be the cause?

Many thanks,
Matt

[rpedde]

@fishfishfish wrote:

Any ideas what might be the cause?

Scanning the metadata incorrectly, maybe?

Can you email or otherwise make a file available to me so I can look at it?

You can email me at [email protected]

— Ron

[fishfishfish]

Great. Thanks. I’m just installing compiling the latest build.

Cheers,
Matt

[fishfishfish]

Could this have anything to do with padding?

I’ve just run mp3info -x on a few files – those that play and those that don’t. The ones that play via my iTunes server have no padding. Those that don’t play have padding. Could be a fluke, but I just thought I’d point it out in case…

Thanks,
Matt

[rpedde]

@fishfishfish wrote:

Could this have anything to do with padding?

I’ve just run mp3info -x on a few files – those that play and those that don’t. The ones that play via my iTunes server have no padding. Those that don’t play have padding. Could be a fluke, but I just thought I’d point it out in case…

Thanks,
Matt

Wouldn’t have thought so, but in any event, it’s libid3tag that does the tag reading. Couldn’t imagine libid3tag would be tripped up by something like that. Me, maybe, yeah. But not libid3tag. 🙂

[Author]

Posts