LinuxMCE Forums

General => Users => Topic started by: colinjones on March 04, 2008, 10:35:23 pm

Title: Beta 4: media browser issues still there?
Post by: colinjones on March 04, 2008, 10:35:23 pm
I have installed the new beta - 2 issues I had with previous versions were:

1. When sorting audio by Genre - all the genres were listed as tiles, but clicking on any of them revealed nothing beneath. I logged a mantis - and apparently it was fixed (due to the query not selecting files recursively below the audio directory)

2. Seemingly with compliation CDs, when sorting by Album, the album appears multiple times as tiles with only one track under each instead of them all being grouped under a single album tile. I believe this may be because each of the tracks has a different performer attribute and these are not getting grouped by the query.

Both of the mantises that I logged for these were closed as fixed in revisions later than Beta 3. But I still get exactly the same behaviour as before - does anybody else still see this?

(BTW - I believe there are several other similar issues in the media grid presentation, but it was confusing to determine for sure so I was waiting until Beta 4 came out and fixed the obvious ones, before I went looking for others)
Title: Re: Beta 4: media browser issues still there?
Post by: totallymaxed on March 05, 2008, 12:08:13 am
I have installed the new beta - 2 issues I had with previous versions were:

1. When sorting audio by Genre - all the genres were listed as tiles, but clicking on any of them revealed nothing beneath. I logged a mantis - and apparently it was fixed (due to the query not selecting files recursively below the audio directory)

2. Seemingly with compliation CDs, when sorting by Album, the album appears multiple times as tiles with only one track under each instead of them all being grouped under a single album tile. I believe this may be because each of the tracks has a different performer attribute and these are not getting grouped by the query.

Both of the mantises that I logged for these were closed as fixed in revisions later than Beta 3. But I still get exactly the same behaviour as before - does anybody else still see this?

(BTW - I believe there are several other similar issues in the media grid presentation, but it was confusing to determine for sure so I was waiting until Beta 4 came out and fixed the obvious ones, before I went looking for others)

Colin please re-open the relevant Mantis's if you believe this to be the case. I will test this in the morning.

Andrew
Title: Re: Beta 4: media browser issues still there?
Post by: colinjones on March 05, 2008, 12:24:43 am
Done. Opened my duplicate ticket as well..
Title: Re: Beta 4: media browser issues still there?
Post by: colinjones on March 05, 2008, 05:02:38 am
OK, update.... after a while (and a reboot) the duplicate album tiles seemed to zip themselves up back into a single album tile! A while later, I had to edit a number of the tracks' album attribute because it was slightly wrong. As soon as I did this and hit resync, each of those tracks were under their own duplicate album tile again. So as a test, I rebooted again, and they all seem to have zipped up again under the correct album tile again! Almost like it is based on an index built as a batch at boot rather than a simple sql query.... haven't seen anything else in the media browser that requires a reboot...

Genre still doesn't work tho...
Title: Re: Beta 4: media browser issues still there?
Post by: 1audio on March 05, 2008, 07:23:36 am
The Music management seems very unfinished and not really organized in a way at least I find useful. I would like the content stored as albums and played as albums primarily. Currently they are stored by artist which makes a mess of compliations and really is tough for my classical collection.

Am I the only one who would like this change? All of the other imaginable sorts can come from the database but keeping albums together in folders I think makes sense.

The other problems can be traced to tagging problems. Some of those should be fixed shortly. If there are no tags the track/album vanishes in that sort.

It seems the ripping software didn't capture tags reliably in flac or ogg. We may need to find a way to recapture the ID3 tag info.
Title: Re: Beta 4: media browser issues still there?
Post by: colinjones on March 05, 2008, 11:48:18 am
1audio - not sure I follow your concerns. In what way do you mean they are stored by artist rather than album? Obviously, there is the file/folder structure, and that isn't effected by LMCE. But in terms of the sorts, this is based purely on the attributes of each track as I understand it.... the media grids are (supposed to be) constructed by grouping together tracks, first by your sort criteria, then by secondary attributes...  in fact this is one of the things that I have logged as an issue. After sorting by album, it is breaking up "compilation" albums into multiple entries because all the tracks have different performers (I believe) unlike normal albums. But this is clearly not by design, and they have already tried to fix this. But it seemingly didn't work. Either way, it isn't a design element.

Moreover, there is an issue here of nomenclature. The GUI menu says "Sort" but in fact it is a grouping. The "sort" is always the same, alphabetical. Then under those grouping, there IS a sort - previously it was also alphabetical. I logged a mantis to get this corrected because you don't want your tracks played alphabetically, you want them played in track order (typically) but this is what it was doing. I have checked with Beta 4 - it does still display them alphabetically, but when you hit Play All it now correctly adds them to the play list sorted by the track attribute.

There are distinct sorts, filters and groupings, but the naming seems to be inappropriate which causes confusion.... I'll shut up now, because I haven't actually got a point :)
Title: Re: Beta 4: media browser issues still there?
Post by: teedge77 on March 05, 2008, 03:40:21 pm
Quote
I'll shut up now, because I haven't actually got a point

LOL. well i think you explained it pretty well and that was helpful.
Title: Re: Beta 4: media browser issues still there?
Post by: 1audio on March 05, 2008, 04:05:46 pm
I was referring to the file structure on the disk. The displayed organization can be completely driven by database sorts.
What format are you ripping to?
Title: Re: Beta 4: media browser issues still there?
Post by: colinjones on March 06, 2008, 12:14:59 am
Quote
I'll shut up now, because I haven't actually got a point

LOL. well i think you explained it pretty well and that was helpful.

Was late and I was tired - lost track of where I was going with all that, and couldn't be bothered re-reading my own post, so I gave up :)
Title: Re: Beta 4: media browser issues still there?
Post by: colinjones on March 06, 2008, 12:18:20 am
I was referring to the file structure on the disk. The displayed organization can be completely driven by database sorts.
What format are you ripping to?

I'm using mp3 - why? Is it important? Actually it is the subject of another of my posts about "gaps" between tracks... I was asking if anybody knew if OGG could handle "chapters" between audio tracks (I know it can for video), so that I could rip an entire CD as a single OGG file, with chapters for tracks. And if so, whether LMCE would see them and honour them as if they were tracks. That seems to be the only way I can get rid of the gaps as the devs are saying it is too hard to change LMCE to do gapless play-back internally .... a real shame if you as me...
Title: Re: Beta 4: media browser issues still there?
Post by: colinjones on March 06, 2008, 10:00:14 pm
Woo Hoo!! Kir sent me a fix overnight for Media_Plugin, I installed it this morning and fantastic, it has fixed the Genre sort (filter) issue. Now when I click on one of the Genre "tiles", all the appropriate media is behind it! Very happy now - thanks Kir! Bit disturbing what genres of music I actually have! Just a process of going through and either correcting the meta-data or deleting the file! (hip-hop? urgh!)
Title: Re: Beta 4: media browser issues still there?
Post by: 1audio on March 06, 2008, 10:53:14 pm
It seems that collecting and imbedding the tags on Flac and Ogg was overlooked. It is being fixed. It was working with MP3. I use only Flac so this has been an ordeal for me.
Title: Re: Beta 4: media browser issues still there?
Post by: colinjones on March 06, 2008, 11:02:59 pm
Glad to here the flac and ogg stuff are being fixed up as well, but the mp3 definitely wasn't working either. I only use mp3 at this stage, and none of the genres had any media behind them. After replacing the binary, bingo, all worked fine!
Title: Re: Beta 4: media browser issues still there?
Post by: colinjones on March 06, 2008, 11:50:31 pm
Woo Hoo!! Kir sent me a fix overnight for Media_Plugin, I installed it this morning and fantastic, it has fixed the Genre sort (filter) issue. Now when I click on one of the Genre "tiles", all the appropriate media is behind it! Very happy now - thanks Kir! Bit disturbing what genres of music I actually have! Just a process of going through and either correcting the meta-data or deleting the file! (hip-hop? urgh!)

Oops, EDIT: just realised it was Ender that sent me the binary...
Title: Re: Beta 4: media browser issues still there?
Post by: golgoj4 on March 07, 2008, 06:34:28 am
Woo Hoo!! Kir sent me a fix overnight for Media_Plugin, I installed it this morning and fantastic, it has fixed the Genre sort (filter) issue. Now when I click on one of the Genre "tiles", all the appropriate media is behind it! Very happy now - thanks Kir! Bit disturbing what genres of music I actually have! Just a process of going through and either correcting the meta-data or deleting the file! (hip-hop? urgh!)

Oops, EDIT: just realised it was Ender that sent me the binary...

will this be released as an update once its tested out?
Title: Re: Beta 4: media browser issues still there?
Post by: totallymaxed on March 07, 2008, 09:00:44 am
I was referring to the file structure on the disk. The displayed organization can be completely driven by database sorts.
What format are you ripping to?

The files are stored in /home/public/data/audio/*artist*/*album*/*track*  if you ripped them with LinuxMCE. If you ripped your audio somewhere else and just copy the ripped files to your Core... or point your Core to where they are already stored then they can be in any file structure you choose without restriction (you will need to have a full set of embedded id3 tags inside each ripped file to ID them accurately though).

The LinuxMCE Media Browser allows you to do two things essentially;

- view the actual file structure of your ripped files
- view the ripped files using the data that UpdateMedia has populated the DB with using the filter/search criteria you choose.

It is this last option - the DB view that we are discussing here. This has two aspects to it in my opinion;

- How has UpdateMedia captured the data about each artist/album/track
- How can you sort/view this data using the Media Browser
Title: Re: Beta 4: media browser issues still there?
Post by: Ender on March 07, 2008, 09:29:59 am
Hi guys,

I've added the issue to beta4's known issues and added the binaries with the fix : http://wiki.linuxmce.org/index.php/KnownIssues_0710_Beta4

Regards,
Ender
Title: Re: Beta 4: media browser issues still there?
Post by: colinjones on March 08, 2008, 01:33:40 am
I was referring to the file structure on the disk. The displayed organization can be completely driven by database sorts.
What format are you ripping to?

The files are stored in /home/public/data/audio/*artist*/*album*/*track*  if you ripped them with LinuxMCE. If you ripped your audio somewhere else and just copy the ripped files to your Core... or point your Core to where they are already stored then they can be in any file structure you choose without restriction (you will need to have a full set of embedded id3 tags inside each ripped file to ID them accurately though).

The LinuxMCE Media Browser allows you to do two things essentially;

- view the actual file structure of your ripped files
- view the ripped files using the data that UpdateMedia has populated the DB with using the filter/search criteria you choose.

It is this last option - the DB view that we are discussing here. This has two aspects to it in my opinion;

- How has UpdateMedia captured the data about each artist/album/track
- How can you sort/view this data using the Media Browser
Andrew - would like respectfully to add to your aspects. I think an extremely important point, that I have been unable to get an answer to yet is how the sync reconcilliation work between DB and ID3 via UpdateMedia. I would really like to see the ID3 as the absolute "master" for any conflict resolution. I have seen instances where the DB will sync back to the ID3s overwriting changes you may have made. Would like to see the sync being multi-master and have some kind of USN or perhaps just using modified timestamps to determine the sync direction, on an attribute by attribute basis - although I recognise that this is a lot of logic! Just would be nice to have certainty that the updates you make in either the web site or directly on files is reliable and doesn't get lost - which does happen currently under some circumstances. BTW UpdateMedia is still getting tied in knots from time to time and stamping lots of extra attributes (esp duplicate ones) on files, and it really messes up the DB views...
Title: Re: Beta 4: media browser issues still there?
Post by: totallymaxed on March 08, 2008, 12:53:38 pm
I was referring to the file structure on the disk. The displayed organization can be completely driven by database sorts.
What format are you ripping to?

The files are stored in /home/public/data/audio/*artist*/*album*/*track*  if you ripped them with LinuxMCE. If you ripped your audio somewhere else and just copy the ripped files to your Core... or point your Core to where they are already stored then they can be in any file structure you choose without restriction (you will need to have a full set of embedded id3 tags inside each ripped file to ID them accurately though).

The LinuxMCE Media Browser allows you to do two things essentially;

- view the actual file structure of your ripped files
- view the ripped files using the data that UpdateMedia has populated the DB with using the filter/search criteria you choose.

It is this last option - the DB view that we are discussing here. This has two aspects to it in my opinion;

- How has UpdateMedia captured the data about each artist/album/track
- How can you sort/view this data using the Media Browser
Andrew - would like respectfully to add to your aspects. I think an extremely important point, that I have been unable to get an answer to yet is how the sync reconcilliation work between DB and ID3 via UpdateMedia. I would really like to see the ID3 as the absolute "master" for any conflict resolution. I have seen instances where the DB will sync back to the ID3s overwriting changes you may have made. Would like to see the sync being multi-master and have some kind of USN or perhaps just using modified timestamps to determine the sync direction, on an attribute by attribute basis - although I recognise that this is a lot of logic! Just would be nice to have certainty that the updates you make in either the web site or directly on files is reliable and doesn't get lost - which does happen currently under some circumstances. BTW UpdateMedia is still getting tied in knots from time to time and stamping lots of extra attributes (esp duplicate ones) on files, and it really messes up the DB views...

Hi Colin,

I agree that the ideal would be to have a 'mult-master' approach as you describe above... and i also agree we are not 'quite there yet'. You've hit the nail on the head also when you say getting this working will require a large amount of 'logic'. The Pluto guys are leading the development of UpdateMedia right now and are doing a great job... but as you recognise it is a big and complex piece of functionality (one that looks deceptively simple when you first look at it though!) to get right. Your right there are still situations where bad attribute data is dumped back into the ID3 tags when things go wrong and we are fighting that bug hard at the moment.

Your feedback and suggestions are immensely helpful to the Dev team and I know they are very much valued by us all - so keep them coming! ... until its perfect of course ;-)