Greetings.
Apologies in advance for github v sourceforge, but I still wanted to share a very handy fork
I expanded upon paddler247's very groovy idea of using the media database itself, rather than some other approaches i've seen which hit the filesystem to look up images for cover art. I made some improvements to support folder and track artwork, and to support a few more name formats, via case folding and regular expressions.
This now really makes mediatomb fully more functional than minidlna.
I'm quite confused by the current state of mediatomb. The "new" git repo on sourceforge is still quite old, and subtly different from what's in the sourceforge download area. It supports a more recent version of JS which crashes hard for me on solaris with pkgin, but that's a whole other thing.
Mainly, again, I'm sharing in the hopes that something like this ultimately makes its way to "upstream" some day.
Cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nice to see someone else working on mediatomb, Ive been beavering away on my own fork[1].
As far as I can see your approach works well when the artwork is sourced from a file on disk, but what if it is handled by a handler (ie from the tags)?
I have been thinking recently that an artwork field in the DB for each object where we can serialise a combination of the handler information, mimetype and perhaps an external (even web) url would be a nice solution?
When the artwork is embedded in the file, the regular mechanisms act as fallback, and things work.
At least that's true for me, in the very specific situation of disabling id3lib and libmp4v2, using only taglib.
id3lib led to a stack smash, libmp4v2 had other issues in my testing, which is on OmniOS [Solaris-like]
I've been having recurring problems with autoscan, which I still don't understand, though I'm trying to see if it's connected to js support; from the .tar source dump to the git version, the spidermonkey version dependency changed, and 185 crashes deep inside spidermonkey, which has put a crimp in my testing so far.
The upside of checking for artwork when requested, rather than serializing to the db, is that it becomes much easier to fix albums by simply dropping cover art, at least when autoscan is working. Knowing that re-serializing should be done would increase complexity of and time of rescan.
Cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
...ooh, thanks for the info on your fork, looks compelling. When I get a chance I'm going to have a try; some of the bundled [and outdated] libraries were annoying me too.
Cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greetings.
Apologies in advance for github v sourceforge, but I still wanted to share a very handy fork
I expanded upon paddler247's very groovy idea of using the media database itself, rather than some other approaches i've seen which hit the filesystem to look up images for cover art. I made some improvements to support folder and track artwork, and to support a few more name formats, via case folding and regular expressions.
This now really makes mediatomb fully more functional than minidlna.
The particular change is here:
https://github.com/whorfin/mediatomb/commit/c3ed3261ff049525eac69ddf4dba303ada2cc84e
I'm quite confused by the current state of mediatomb. The "new" git repo on sourceforge is still quite old, and subtly different from what's in the sourceforge download area. It supports a more recent version of JS which crashes hard for me on solaris with pkgin, but that's a whole other thing.
Mainly, again, I'm sharing in the hopes that something like this ultimately makes its way to "upstream" some day.
Cheers
Hi Rick,
Nice to see someone else working on mediatomb, Ive been beavering away on my own fork[1].
As far as I can see your approach works well when the artwork is sourced from a file on disk, but what if it is handled by a handler (ie from the tags)?
I have been thinking recently that an artwork field in the DB for each object where we can serialise a combination of the handler information, mimetype and perhaps an external (even web) url would be a nice solution?
When the artwork is embedded in the file, the regular mechanisms act as fallback, and things work.
At least that's true for me, in the very specific situation of disabling id3lib and libmp4v2, using only taglib.
id3lib led to a stack smash, libmp4v2 had other issues in my testing, which is on OmniOS [Solaris-like]
I've been having recurring problems with autoscan, which I still don't understand, though I'm trying to see if it's connected to js support; from the .tar source dump to the git version, the spidermonkey version dependency changed, and 185 crashes deep inside spidermonkey, which has put a crimp in my testing so far.
The upside of checking for artwork when requested, rather than serializing to the db, is that it becomes much easier to fix albums by simply dropping cover art, at least when autoscan is working. Knowing that re-serializing should be done would increase complexity of and time of rescan.
Cheers
...ooh, thanks for the info on your fork, looks compelling. When I get a chance I'm going to have a try; some of the bundled [and outdated] libraries were annoying me too.
Cheers
+1 for v00d00 branch
https://github.com/v00d00/mediatomb
My cover art changes are now merged, and i'm deleting the sourceforge-pulled git i started with in favor of forks of v00d00 for future hacking.
The v00d00 branch has resolved my autoscan problems, and been running solid for me so far.