Connected Themes
Album art creates a jpeg for every track
OfflineSo I've just given up on hoping for a way to get the server to correctly find and assign my album art, and begun doing it by hand. All 1500 albums.
However, after 5 or so albums, it quickly became apparant to me that the server is creating a jpeg of the album art for each track. The images are all contained within the tracks folder and are named identicaly to the MP3.
So what's with this? Something must be going wrong because this would be an incredibly sloppy and poor way of implementing album art on the box. I already have one copy of the album art, named how I want it, in every album folder. This is enough. If the server wants to keep it's own version of the image then it should do so in it's own database or at least in a folder within the installation folder. And even so, there's absolutely no need to create a fresh jpeg for every track in an album when the art is the same.
Please advise.
Connected Plug-ins
License Agreement
NO COMMERCIAL USE: This License Agreement grants our community members the right to use the Software downloaded from DivX Labs for personal use only in order to evaluate and provide feedback about it to DivX, Inc. Commercial use of the Software or of the work products resulting from its use is not permitted under the Terms of Use of DivX Labs.- To read the full Terms of Use please visit the Terms of Use page.
- To inquire about commercial licensing please email us
I haven't followed in detail what you are discussing as I have not encountered any problems with album art.
But I thought it might be useful to say that I use MediaMonkey (free software) to fetch and assign album art to the tracks. I don't know quite how it works but there is no jpg files created, the album art seems to be embedded in the mp3 file. My DSM330 recognises this and shows all the correct artwork.
My only problem with this method is that on some albums I have a number of images(front cover, rear cover etc.) and I don't think there is a way for the DSM330 to display more than one.
Hope this helps.
The trouble with that method is that you really have the same situation which the poster has a problem with. If you go that way, you add the albumart into each file. consequence is that you effectively create a bigger file, resulting in more diskspace being taken up with redundent data.
Imagine a folder with 12 song all sharing the same albumart. Instead of having 1 image for all the songs of say 30 KB, you'll end up with 12 bigger files resulting in 12 x 30 KB (effectively even bigger as they are imbedded) = 360 KB. For a small collection this might not be a problem, but if you have 10.000+ songs this will take up a lot of unnecessary space (like 292 MB).
So when I assign the album art I unwittingly make a number of copies of it.
I have just totted up how many tracks I have and how much space is taken up with these graphics. I believe that the album art probably occupies around 0.4%. Your right that this is unneccessary wastage but isn't really a big deal percentage wise.
The other nice thing is that I can move the file to another player and the album art isn't affected.
percentage wise it not that big of a deal.
However, embedding all my albumart in the songs is work i can do without.
Especially if the database is modeled so, that i shouldn't have to.
I use wmp11 because it there, and does all that i need it to (which is just rip and add albumart), and don't want to spent time maintaining my music library every time i add a new CD.
I guess in that respect i'm more like Joe Sixpack.
As will be most consumers....
WMP is (like it or not) still the most commonly used music library, and as such should be supported. The same goes for itunes.
(Which i will never, ever, install on my PC, but maybe thats just me)
The jpg for every track is not a bug, but that is currently how it is designed. If users would prefer, we can look into having an option to enable/disable by default.
Registry_Editor-
Updates take time, but I can assure you that DivX reads these forums and the user feedback and uses that feedback to plan for future updates. A lot of the newer features are here because beta testers, and current users have requested them.
[dan]
I'm sorry slightlyoffbeat, but that is simply not true.
As you can read in my posts, this is not how it is designed (from an architectural point of view), and i consider this to be a very important bug to be resolved.
Effectively you've implemented 3 different ways to do albumart, and ended up with a jpg for each song, aswell as a jpg in the images folder. And both are not necessary! I suggest looking over the current DB model you're using. I'm sure you'll reach the same conclusion.
Actually your response makes me quite angry....
(not personally intended)
It's the kind of response i get from programmers who are to lazy to fix there code, and try to get away with it.
Just do us all a favore, and fix this.
That way we're all better off.
(or are you seriously considering keeping things this way?)
Slightly offbeat - You're saying the "One jpg for every track" thing is not a bug. Who on earth thought it would be a good idea then? It's the worst implementation of album art I've ever seen (and believe me, I have seen some atrocious setups).
I have just under 10,000 tracks in my media library currently. The jpgs created by the server seem to range between 25kb and 35kb, lets average that to 30kb. 30kb x 10,000 tracks = 292mb of Wasted disk space, not to mention the immense bloating of the folders and the increased volume of entries in the file allocation table. Oh and lets not over look the fact that if I updated the album art for every album on the server, I'd suddenly have over 20,000 files in the music folder, rather than 10,000.
Honestly - I can't believe I'm having to make this post. You can't seriously be expecting to leave the system like this?
Like I've said in a previous post - a proper implementation would either be to store one image for each album in a database in the Connected install folder, or to create one HIDDEN copy in each album folder.
I don't know what you mean by 'an option to enable/disable by default'. But if you're saying a user should be able to chose between this ludicrous system, or no album art at all then thats not a choice.
There won't be an .jpg for each file.
Divx uses an MD5 hash to determine whether the .jpg file allready exists. They then link every occurrence to that .jpg
Also, all jpeg are copied to the /images folder.
So long as they won't use albumart in the music folders themselves, but only the in the mp3 embedded albumart, this is the correct way to do this. Work wonders for the movie stills aswell.
Actually the database they use is allready capable of storing the compleet path to the .jpg.
As i'm not to familiar with SQLite3 perhaps someone from Divx can make a small script to add the albumart in corresponding music folders to the database. Everything is allready in place, so this would not be to hard, and will help out all the users (myself included) that have extended music libraries with albumart in the folders, and not embedded in the mp3. Really, adding the albumart one song at a time is not the way to go.
Now I'm a little confused. What you describe above is how I would imagine the system to work. However I can asure you that going to an album folder on the DivX Server, selecting all the tracks and assigning them the cover jpg creates a brand new jpg in the folder for each track.
Please help! I can't find any way to fix this!
When u manually add albumart to a song, divx copies the albumart to
"C:\Documents and Settings\Admin\Local Settings\Application Data\DivX\DivX Connected\DB\01\Images".
In the database they add the path of this newly create image, add its hash (Md5) and link it to the occurrence of the song.
They use the hash to determine if the image is allready present when importing the embedded albumart. So you shouldn't get the same file again when adding the albumart to the next song. However, They also make a extra image in the music folder, which does nothing, and isn't even know to the application.
All they have to do, is not do that...... this is clearly not an intended functionality, but a BUG!
(and a very annoying one)
The best way would still be to not copy the file to the images folder in the first place, and add the path to the allready existing image.
No sense in creating a new file if there is allready a usable one present.
That is, if they decide to search not only for embedded albumart, but also check whether there is albumart present in the music folder.
What i was trying to say is, there is no architectural reason for the current lack of functionality. They just haven't done the code yet. So should be easy.
(hope i was able to make things a litte clearer)
If i was a little more familiar with SQLite3 i might have done this myself.
((un)fortunatly i'm a software designer, not a programmer) :-)
Also, i hope they have implemented a vacuum of the database every so often. Otherwise preformance might suffer after some moving / adding / deleting files and folders.
Mine is allready a mess. :-(
(i moved media to an new 500 GB HDD, and did some reordering)
And.... they really should have delete the old resource files after updating. No use in keeping over 2 GB of useless data.
So are you saying that if I delete all the extra jpegs that have been created, the album art will still display on the box?
At least it does for me.
If you look in the folder from my previous post, you'll seen that the images are present. (named pf-xxx.jpg)
i've written a small (and very ugly, boy i really need to refresh my programming skills!) script myself which does it all for me, but it currently runs with ms access 2003 as it requires an odbc connection to the SQLite3 DB. When i have time i'll try to figure out how to do this directly using the SQLite3 .dll and provide an .exe that does it for you. Currently a bit to busy with other things, but i'll try to look into it next weekend.
Really a shame we have to do this in the first place though.
In iTunes you can select a group of songs and add the album art to all those songs.
Simple really.
Trouble is, well just read my response to Greenman...
I've encountered the same problem.
Somehow the server will not recognize the WMP11 album art, and with the problem you just described manually adding the album art is just selftorture.
The whole music implementatie is just not finished.
Things like album art, correct sorting order, etc, are basic things which should be working by now...
Oh by the way - I think WMP11 keeps the album art somewhere other than where the album is, or it hides the art. I have all my album art in the album folders, named "Front Cover.jpg" . So the server won't even recognise logicaly named/located images from the album folders.
WMP11 uses hidden jpg files located in the corresponding folder.
The album art has a standard name: folder.jpg.
How hard can it be to use these pictures with all music files in the folder?
I think that DivX forgot to add the track number when they did there database upgrade. Again, read the correct tag from the track, add this to the database, and implement a sort order by track number. Not having done any coding for several years, i think i can do this in under a hour.
These are not difficult architectural problems they'll have to solve.
I know there are some real difficuties to overcome in the flash (no sound) department as well as the HDMI trouble they're currently facing, but just spare a junior programmer to add these minor fixes.
It feels like they're only focused on these big issues, all the while not even bothering with all the other changes/requests put forth by the testers / community.
Agreed. It seems as though the people at DivX consider DivX Connected a side project and only work on it occasionaly. Even with just one person working on it every day, I would have expected to see many more features incorporated and bugs fixed by now.
Can we get some word from someone who actually works on this project? When are these basic features going to be sorted out? Why are we waiting so long, with only a few new features in each update? How many man hours per week are being spent on this?