Hi Jörg, Thanks for your detailed feedback, it is much appreciated. > Hi, > > first of all: Thanks a lot for this great piece of software. I got it > working on sidux which is Debian Sid, but with a mixture of package > installation and compilling, I finally got 0.3.5 working - the original > Debian package gave an unresolved pgm dependency error... I am using VDR > as PVR solution for several years, but due to some limitation with > Non-DVB-content, I think about using Elisa especially for MP3, DivX > (e.g. taken from a NAS) and YouTube playback. > > Finally, here are some issues I got with Elisa 0.3.5
> 1) Problems with MP3s with APEv2 tags: > For tagging the MP3s, I use the windows tool MP3tag (www.mp3tag.de) > which I also got working yesterday with wine on linux. Among a lot of > features there is an option where I can tell what type of tags to write. > I previouly set it to ID3v1, ID3v2 and APEv2. The last one, APEv2, > caused Elisa to display some weird combination of numbers and destroyed > umlauts. After removing the APEv2 tags, it worked without problems. So > Elisa or one of the used components is not "compatible" with APEv2 tags. That's indeed a bug, APEv2 tags should be supported with GStreamer's apetag plugin (in good, http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-plugin-apetag.html). Now for determining whether the bug is in GStreamer or Elisa... Can you try `gst-launch -t filesrc location=myfile.mp3 ! apedemux ! fakesink` on such a file and paste the output somewhere? Or make such a file available to us so we can try? On a side note, I don't know much about APE tags but what's the point of having the same metadata duplicated three times? ID3v1 is known to be limited and players that don't support ID3v2 are of another era... > 2) No cover view from (embedded) jpegs > For getting the best "cover compatibility" on all hardware and software > players available, I stored covers in 2 ways. > - Windows Media Player and Windows Media Center look for a file called > folder.jpg oder Folder.jpg in the same directory as the MP3s. Looking > into coverindir_metadata.py, both names are not supported. Adding it to > the code in line 55 or renaming folder.jpg to cover.jpg did not work. > Furthermore, I don't want to include the same jpeg with different names > in the same folder - I would rather prefer this non-standardized M$ way. I haven't tried it myself, but simply adding 'folder' or 'Folder' to the list_of_names list in coverindir_metadata.py at line 55 should work. Is the plugin actually activated in your configuration (check for its presence in the list of metadata_providers in ~/.elisa/elisa.conf)? > - iTunes embeds the JPEGs directly into the MP3 file. I also did so with > MP3tag, but the covers are not being displayed. > Is the Album Art Plugin disabled at all? Amazon search often gives me > wrong results and the image quality is not the best (iTunes often gives > you 600x600px covers which I download with the iTunesVerifier and embed > manually). So I would prefer if Elisa looked for embedded or separated > jpegs before it searches the web - if it does the latter at all because > I might prefer rather a placeholder than a wrong cover. As for embedded covers AFAIK we don't support that at the moment, but it would be a nice-to-have feature, definitely a more reliable source than Amazon for covers, although we need to check if the format used to embed them is somewhat standard. Can you open a ticket in our bug tracker (filed as an enhancement) to track the implementation? -> https://code.fluendo.com/elisa/trac/newticket > 3) Case sensitive sort order > Could you change the sort order e.g. of the artist list to a case > insensitive sort order? Having artists like "a-ha" on a very different > position than e.g. "A*Teens" is quite strange as a lot of people also > don't ever recall the correct spelling of some artists. Sure enough that's a bug, could you please either file a new ticket or update ticket #810 which is somehow related? -> https://code.fluendo.com/elisa/trac/ticket/810 4) Navigating > through a MP3 collection > If you have a collection with a lot of artists, scrolling through the > list is quite slow compared to the number of database entries - > especially if there are really several hundred artists. I see two > different ways accelerating this: > - Pressing the keys 1 to 9 to jump through the list with 5 jumping to > the middle of the list, 1 to the beginning and 9 to the last part of the > list/end. > - Jumping with an SMS style control using the numbered keys. Pressing > "2" will bring you to "2" on the first press, to "a" on the second > press, "b" on the third press and "c" on the fourth press etc. > - Some kind of search functionality using the SMS style control might be > the fastes way to find something. Although I am not a mobile phone > freak, an implementation of a search field might also help finding > videos in the YouTube plugin section. As for numbers based list navigation, it is already implemented, see ticket #449 (https://code.fluendo.com/elisa/trac/ticket/449). As for the search functionality, we are currently working on it, trying to come up with an easy to use and convenient widget for such search features. As soon as this widget is available, we'll enable cross resource providers search. > 5) No "working" sign when reading the database > As I have a big list e.g. of artists, selecting Audio/Artists causes > Elisa having a break when pressing the "ok" key. As a user, you don't > know if Elisa has reacted on pressing the key of if Elisa is busy > reading the database. So I would like to see the "working" sign before > anything is being read from the database. Definitely. The best of course would be to have no latency, but in any case Elisa should display a busy indicator... Please file a ticket for this, thanks! > I hope that you find any use of my feedback ;) > > With kind regards > > Joerg Thanks again for your feedback! Regards, Olivier
