Beta 4: media browser issues still there?

[totallymaxed]

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

[Ender]

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

[colinjones]

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...

[totallymaxed]

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 ;-)