Increase number of media sources and add direct support for specific media streamers
Increase number of repositories searched (I'm thinking here of Google images, Amazon etc. although they might get a bit annoyed with copyright etc.)
Allow for optional naming of jpg file. For example allow the jpg to take both "folder.jpg" and/or parse the name of the Album as the title of the jpg e.g. Beverley Knight >> Affirmation >> Affirmation.jpg or to allow a custom extension to be chosen.
This leads onto support for specific media streamers. In my case the Western Digital TV Live Streaming Media Player.
WD have chosen to use freebase.com as their meta data source but freebase is woefully inadequate in so much as it fails to find most of my stuff and the source can't easily be changed, hence the use of bliss.
WD employ an xml scraper to retrieve meta data for the music and (when it actually works) creates an xml file of the data scraped and a thumbnail as <Album Name>.metathumb within the album directory.
The metathumb is simply a jpg that has been renamed and appears to be 150x150 in size.
It would be great if bliss could add this additional scraping facility from a chosen source and save it in the required format.
This would greatly enhance the set-and-forget capability on my Synology NAS to which my WD TV Live is connected
Thanks Andrew. To clarify: where are those filenaming conventions and string replacements important?
Just drafting a new idea for the scraper which I will refine over the next day or two. Having had a think about the requirements of my idea, I think the important thing for me is for bliss to support the ability to save the jpg file as Album Name.thumb (I thought it was metathumb but I was incorrect) within the album directory.
In terms of filenameing convention spaces seem to be replaced by "%20" and apostophies by "%27" as per the hex code for the character.
Then the rest of my idea can be tidied up.
Ok, assuming you have enough votes left, could you create a new idea for the scaper idea? Describing what it does (you can just copy and paste).
I can change this idea to be the control over filenames.
The 'support for more media streamers' can only really be added when the media streamers that are required are named, and the nature of the support is described. I need these ideas to be 'SMART' - http://en.wikipedia.org/wiki/SMART_criteria
"More control over the image file name" works for the one suggestion. The second suggestion might be something like "Add xml scraper support" or "Add direct support for specific media streamers".
Ok, I'll change the title to "More control over the image file name" and do a little editing of the description (remove the first para, maybe introduce with the concept of more control over the filename and then have the rest of how this works with the WD TV Live). Is that ok?
I can post up a sample directory structure later today but in essence the structure is <music>/<Artist>/<Album>/01 Song.ogg ... n Song.ogg
Artist and Album definitions are defined by the ripper settings so are controlled. As you know, in theory they should match the ID tag but sometimes the tag differs. My MO is to rewrite the tag to match Artist and Album directory. bliss creates folder.jpg in the Album/Artist directory and would need to rename or copy folder.jpg to Album.metathumb. The WD scraper will also create an Album.xml file in the same directory with blurbs about the artist/album where available.
Ignoring the xml element I currently cp folder.jpg Album.metathumb manually. That way I can maintain a dgeree of interoperability with other media devices.
The WD is a bit strange and inconsistent in the way it handles cover art. As far as I can tell when the WD connects to the NAS as a media server it makes limited use of folder.jpg but when you connect as an NFS or SMB share (necessary to complie your media library) it scrapes the necessary metadata and generates a .metathumb file of zero length if it can't find the cover art or whatever the file size is of any art it finds.
Hope this clarifys things?
Ok, now I see why you said "This leads onto support...". If you had the control over the filename you could do that, right?
Sorry for the confusion. I kind of guessed that you would split them. Regarding the metathumb suggestion. It is the latter clarification i.e. bliss simply renames the .jpg as .metathumb while parsing the Album name/parent directory name as the file title.
Thanks for this Andrew. It's always interesting to hear of specific uses with different pieces of hardware/software.
I really want to keep to a one idea:one thread approach so it's easy to measure how in demand different features are. In this idea I count at least three ideas, so I'd like to split them:
* Increase number of sources
* Allow for optional naming of external files
* Better interoperability with the WD TV Live metadata facility
For the first one, I've already declined http://ideas.blisshq.com/forums/21939-bliss/suggestions/2980994-more-cover-sources and I'd want specific sources to be suggested, ideally one per thread again. WRT Google and Amazon, both of these do not allow automated querying of their API via bliss. Google allows manual querying (which is why bliss uses it for the change cover art screen). Amazon changed their ToS recently to stop certain accounts that don't sell etc via Amazon, which stopped bliss using Amazon. So please don't add either of them.
The optional naming of the external files is a great idea and should be in a separate thread I think. I could add my own ideas about how this could be parameterised.
Which leads me to the meat of this idea, I think. Unfortunately I don't fully understand whether you are asking for bliss to read the .metathumb files (and so use this data to populate tags inside your music files), or bliss to write the .metathumb files from the data it finds (and so help the WD TV Live to show data that bliss has found).
I think all of these ideas are valid, I just want to organise them appropriately so that they can be voted for and the votes mean something.