open files with art_filename

[volker]

I’ve just look (for debugging something else) after the open files on my Debian-System. (lsof) My server runs for the last 7 Days and every imagefile for mt-daapd from the last days is shown as open. Is this normal?

greetings, volker

[rpedde]

doh. I’d guess not. 🙂 I usually run a valgrind a server for a couple days every couple months just to make sure I find stuff like that. I do filehandle checking, but now that I’m thinking about it, I don’t run art_filename (all my mp3s have embedded art — damn the diskspace, full speed ahead!)

Is it on aac files or mp3 files? They have different code paths.

I’ll put this on my list.

— Ron

[CCRDude]

May I add a question or feature request regarding art_filename?

I don’t have files with fixed names for my albums, but I have two kinds of images:

1.
Radio Plays/Radio Play 1.mp3
Radio Plays/Radio Play 1.jpg
Radio Plays/Radio Play 2.mp3
Radio Plays/Radio Play 2.jpg

2.
Artist/Album/Tracks.mp3
Artist/Album (front/back/cd).jpg

So what about, instead of a fixed art filename like it is currently, take the full mp3 filename and just look for graphic files with the same but different extension? “(filename without extension).jpg”?

Second thing would be more complex, something like take first search result for “(path minus last slash)+*.jpg”? Or maybe “(path minus last slash)+(config-defined string).jpg”?

[volker]

rpedde wrote:

Is it on aac files or mp3 files? They have different code paths.

It’s all mp3. My only aac-Files are these I buy by Apple and for these art-filename doesn’t work.

greetings, volker

[rpedde]

volker: it actually *should* work with m4p — there isn’t a hash or anything on the metadata, as I understand it, it’s just the mdat atom that’s encrypted, and as long as one doesn’t mess with mdat or wherever the IV is stored (can’t remember off the top), I think you can do whatever you want.. upshot should be that it will work.

All my m4ps are off my machine on backup, but I guess I could dig one up and check it.

I’ll turn that one, and see if I can find the leak in the mp3 file handle.

CCR: That doesn’t sound like a bad idea, I just don’t know how you would specify that in the config file. Maybe that could be a “secret” fallback… if it doesn’t find the art_filename specified, then just try the filename.

Or vice versa. Check the filename.jpg, and then the art_filename.

Lemme mess with it.

[volker]

rpedde wrote:

volker: it actually *should* work with m4p — there isn’t a hash or anything on the metadata, […]

Your right. It works, but only if I rename the file from .m4p to .m4a

By the way: mt-daapd havn’t recognise the renamed file by clicking “start backgroundscanning” in the webfrontend.

greetings, volker

[CCRDude]

Ron: what I had in mind at first was something like this:
art_filename .jpg
art_filename (cd).jpg
Where mt-daapd would simply replace the part in brackets by the actual filename or path where necessary.

Of course a fall-back from the art_filename value to the mp3 filename or vice versa may even be better 🙂

[CCRDude]

LOL just saw that the HTML in the board broke what I tried to write…
What I tried to write was templates like:
<$mp3file>.jpg
<$mp3path> (cd).jpg
(hope writing the HTML entities for the brackets work)

[rpedde]

Gotcha.

I’m going to do the easy case first. I’ve also ripped some stuff in lossless wma so I have some test files to work with on wma metadata.

I’ll post back here when I have something.

— Ron

[rpedde]

open fd bug fixed in cvs and latest nightlies.

– Ron

[Author]

Posts