Album view: looks at other fields in MP3s with blank Album, creates multiple folders (1 Viewer)

[doveman]

MediaPortal Version: v1.2.1
MediaPortal Skin: StreamedMP
Windows Version: Win7 Ult 64
CPU Type: Phenom II X4 955
HDD: 2TB Samsung F4
Memory: 8GB DDR3 1600Mhz
Motherboard: MSI 990FXA-GD80
Video Card: HD6950 2GB
Video Card Driver: 11.12
Sound Card: onboard Realtek AC97 (ALC892)
Sound Card AC3: no AC3
Sound Card Driver: 6.01.6482
1. TV Card: Hauppauge Nova-T 500
1. TV Card Type: DVB-T
1. TV Card Driver: 4.3.27240
MPEG2 Video Codec: Cyberlink PDVD11
MPEG2 Audio Codec: ffdshow
h.264 Video Codec: MS DTV-DVD
Satelite/CableTV Provider:
HTPC Case: Custom
Cooling: Scythe 120mm Bottom Intake Fan, TRUE Rev. c CPU HSF
Power Supply: Antec CP-850
Remote: Nova-T 500
TV: Sony XBR800 36"
TV - HTPC Connection: DVI

Album view groups all my MP3s with blank Album data under a single folder. However, if some of those tracks have other data, such as AlbumArtist and DiscNumber, this results in Album view creating multiple folders, each with multiple subfolders.

Actually, the multiple subfolders problem can be dealt with by removing the second tier (discnumber) from Album view and I understand why some people will want this tier and that it probably can't work one way for the folder with the MP3s with blank Album data (singles) and a different way for the rest of the actual Albums. I don't think I need the discnumber tier though, so it's no problem for me if I delete that to avoid this issue.

However, Album view still creates multiple folders if the Album data is blank but the AlbumArtist varies (e.g. if all the tracks have AlbumArtist - Single, except for one which has the AlbumArtist - Singles, this will result in two folders, with the second just containing the track tagged AlbumArtist - Singles). I don't think it's useful to have multiple folders created like this and it would make more sense to have all tracks with blank Album data just grouped under one folder.

 

[elliottmc]

Re: Album view: looks at other fields in MP3s with blank Album, creates multiple fold

Album view groups all my MP3s with blank Album data under a single folder. However, if some of those tracks have other data, such as AlbumArtist and DiscNumber, this results in Album view creating multiple folders, each with multiple subfolders.

As you note below, you have a discnumber level in the album view, so if there is something in this field, it will create this folder (layer). If it didn't do this, it would be a bug.

Actually, the multiple subfolders problem can be dealt with by removing the second tier (discnumber) from Album view and I understand why some people will want this tier and that it probably can't work one way for the folder with the MP3s with blank Album data (singles) and a different way for the rest of the actual Albums. I don't think I need the discnumber tier though, so it's no problem for me if I delete that to avoid this issue.

However, Album view still creates multiple folders if the Album data is blank but the AlbumArtist varies (e.g. if all the tracks have AlbumArtist - Single, except for one which has the AlbumArtist - Singles, this will result in two folders, with the second just containing the track tagged AlbumArtist - Singles). I don't think it's useful to have multiple folders created like this and it would make more sense to have all tracks with blank Album data just grouped under one folder.

I would argue that this is the expected behaviour, and therefore no bug.

If two tracks are tagged as having a different albumartist, then MP can expect them to be from different albums, and so should create separate folders in the view.

Mark

 

[doveman]

Re: Album view: looks at other fields in MP3s with blank Album, creates multiple fold

I would argue that this is the expected behaviour, and therefore no bug.

If two tracks are tagged as having a different albumartist, then MP can expect them to be from different albums, and so should create separate folders in the view.

Mark

That makes perfect sense for the Albums, but for single tracks (identified as having blank Album data) it just results in creating lots of useless folders, so if MP could be made to ignore the AlbumArtist when Album is blank, that would be much better and not affect how actual Albums are displayed.

 

[elliottmc]

Re: Album view: looks at other fields in MP3s with blank Album, creates multiple fold

I give in.

You simply want album view to properly display things that are not albums, and you want it to guess correctly what you want.

Again, I simply give in.

Mark

 

[doveman]

Re: Album view: looks at other fields in MP3s with blank Album, creates multiple fold

I give in.

You simply want album view to properly display things that are not albums, and you want it to guess correctly what you want.

Again, I simply give in.

Mark

Well I'm sorry to see such an attitude to a simple request to consider making the Album view more convenient. I really don't think I'm the only person to have singles (i.e tracks not from Albums or with Album data) or that no-one else would find it handy to be able to access their singles without having to switch from the Albums view (as they can now, but by creating extra folders for tracks with blank Album data but various AlbumArtist data it makes a mess).

No one's asking MP to "guess" anything. It's a program, so if programmed to put all tracks with blank Album data in one folder (irrespective of any other data) that's what it will do, without having any impact on the display of Albums (i.e. with Album data). Clearly there's never going to be an actual Album with blank Album data, but proper AlbumArtist data!

Again, I'm sorry to see such an attitude and an inability to appreciate how this could improve MP.

 

[mm1352000]

Re: Album view: looks at other fields in MP3s with blank Album, creates multiple fold

Hi doveman

What you have suggested seems to me like a workaround on top of a workaround. Generally we try to avoid things like that because they make software tricky to maintain. Sometimes software doesn't work the way we want and if we aren't willing or able to customise it for our requirements and other people don't see things the same way we do then we either put up with it or find other software.

Please don't take this the wrong way. I fully understand that you're trying to help us to improve MP. From a team perspective sometimes the multitude of issues that you raise, expectations that you have, and the way that you articulate yourself are difficult to deal with. You referred to this as a "simple request" - I'd like to remind you that even things that might seem conceptually simple to you are not necessarily simple in code. On top of that there is the testing that must be done to ensure changes don't break/affect other functionality. It is more work than you might imagine. I think it is clear from Mark's response to you that the way that you're interacting in regard to this topic is causing frustration. Telling team members that they have a poor attitude because they don't agree with your viewpoint is not helpful and I'd respectfully ask you to refrain from doing that in future.

mm

 

[doveman]

Re: Album view: looks at other fields in MP3s with blank Album, creates multiple fold

Hi doveman

What you have suggested seems to me like a workaround on top of a workaround. Generally we try to avoid things like that because they make software tricky to maintain. Sometimes software doesn't work the way we want and if we aren't willing or able to customise it for our requirements and other people don't see things the same way we do then we either put up with it or find other software.

Please don't take this the wrong way. I fully understand that you're trying to help us to improve MP. From a team perspective sometimes the multitude of issues that you raise, expectations that you have, and the way that you articulate yourself are difficult to deal with. You referred to this as a "simple request" - I'd like to remind you that even things that might seem conceptually simple to you are not necessarily simple in code. On top of that there is the testing that must be done to ensure changes don't break/affect other functionality. It is more work than you might imagine. I think it is clear from Mark's response to you that the way that you're interacting in regard to this topic is causing frustration. Telling team members that they have a poor attitude because they don't agree with your viewpoint is not helpful and I'd respectfully ask you to refrain from doing that in future.

mm

I half expected to get told off! I followed elliotmc's request in my original thread to start separate threads about what I perceived as bugs and after having tried to explain my reasoning behind this suggestion, I get "I give in. Again, I give in" which is hardly respectful and is what someone says when they think someone is being stupid or dense, and this is what I found to be a poor attitude.

I'm sorry if you (and the rest of the team) are unhappy with me identifying several things that aren't as user-friendly as they could be and making suggestions as to how they could be made more so. The only "expectation" I have is that the team would want to try and make MP as user-friendly as possible, and are willing to consider any suggestions to that end with an open-mind. I'm not sure what you mean by "the way that you articulate yourself" either, as I always try to be polite until I feel I've been insulted or disrespected.

This is a simple request, which doesn't mean I don't appreciate it may take more work to implement than anyone thinks is acceptable, and if someone said "That's a reasonable idea, but we don't have the time to do it any time soon" I could accept that but being accused of asking for things I haven't (i.e. making MP able to "guess" what I want) and what appears to be just pedantry and refusal to consider whether a suggestion would be beneficial to users is really not on.

It's becoming increasingly depressing the response I'm receiving to my suggestions and frankly I'm getting to the point where I can't be bothered to spend the time testing things and explaining my suggestions, only to find no-one's willing to properly consider them, gives me attitude and then I get scolded for reacting (when it's a team-member at least).

If this is the way you want to run the forums and the MP project, that's up to you and I'll just sit back and hope it develops into something better one day, without my help.

 

[elliottmc]

Re: Album view: looks at other fields in MP3s with blank Album, creates multiple fold

I have actually spent a great deal of time considering your suggestions carefully.

To me, the issue is very simple. As far as I can see, MP is behaving in a perfectly logical way based on the way you have your music tagged. If you have disc numbers and a discnumber layer in your view, then this will be added. Unfortunately you expect MP to ignore this if certain criteria are met.

When team members try to explain the situation to you, you simply argue.

I have spent a great deal of time ensuring that my music is correctly tagged, so that MP can handle it. MP cannot guess what you would like, and two users with (apologies) incorrectly tagged music will expect two different outcomes. We can't get it right for everyone.

Please can I suggest that you take a step back from these issues and consider the following.

1. Most of the team members have jobs, families and very little free time. We spend time on MP because we genuinely want to make it as good as it can be.

2. We can't fix everything, or make it all things to all people. There are not enough of us.

3. It is actually going to be quite easy for you to tag your music to give exactly what you want in album view. There are many good programs that will allow you to tag your music.

4. Let us stick to the issues that are geniune bugs (for example the way tags don't seem to be handled in wav files - I can't test this myself but it does sound like a bug).

This is not to say that we want you to stop reporting issues and inconsistencies that you find. Just that when a couple of team members tell you that this is the expected behaviour, try to see things from other perspectives. Maybe changing things to display your music the way you expect will cause problems for others.

Ultimately, the code is available, so if you want to try to understand it and fix it to work the way you want, there is nothing stopping you doing this. Personally I don't have the ability to do this, so it is easier for me to tag my music so that it works.

Best wishes,

Mark

 

[doveman]

Re: Album view: looks at other fields in MP3s with blank Album, creates multiple fold

I have actually spent a great deal of time considering your suggestions carefully.

To me, the issue is very simple. As far as I can see, MP is behaving in a perfectly logical way based on the way you have your music tagged. If you have disc numbers and a discnumber layer in your view, then this will be added. Unfortunately you expect MP to ignore this if certain criteria are met.

The frustration comes from having my input misrepresented or not engaged with. I clearly said in my first post that I understand why the discnumbers create a second tier and that I had found a way around this to suit me, so to say I expect MP to ignore this or behave differently is grossly unfair.

When team members try to explain the situation to you, you simply argue.

Again I don't believe it's fair to characterise my input as "arguing". I explained why I thought it would be better if tracks with no Album data were all grouped in one folder, which you didn't engage with in your first reply, so I politely tried to explain again as you didn't appear to understand what I was saying, and then rather than engage with my point you said "I give in" and accused me of wanting MP to do the impossible. I then again tried to explain how I think my approach could make life easier for users.

I have spent a great deal of time ensuring that my music is correctly tagged, so that MP can handle it. MP cannot guess what you would like, and two users with (apologies) incorrectly tagged music will expect two different outcomes. We can't get it right for everyone.

That's one of the issues I'm trying to consider. Whether it's possible to make MP operate in a way that reduces the amount of time users have to spend correctly tagging their music. Obviously this won't benefit you as you've already spent the time to do this, but that doesn't mean many other (potential) users can't benefit from it. I don't dispute that my music isn't all correctly tagged and I'm also willing to accept that there may be so many variations on this amongst users that implementing my suggestion wouldn't benefit many users but as far as I can see, if users only have to ensure the Album data is blank for their singles to appear in one folder that would seem to work for everyone and require the least effort on the users' part. If you can show me how I'm wrong on this point, I'm perfectly willing to consider what you have to say.

Please can I suggest that you take a step back from these issues and consider the following.

1. Most of the team members have jobs, families and very little free time. We spend time on MP because we genuinely want to make it as good as it can be.

2. We can't fix everything, or make it all things to all people. There are not enough of us.

3. It is actually going to be quite easy for you to tag your music to give exactly what you want in album view. There are many good programs that will allow you to tag your music.

4. Let us stick to the issues that are geniune bugs (for example the way tags don't seem to be handled in wav files - I can't test this myself but it does sound like a bug).

This is not to say that we want you to stop reporting issues and inconsistencies that you find. Just that when a couple of team members tell you that this is the expected behaviour, try to see things from other perspectives. Maybe changing things to display your music the way you expect will cause problems for others.

I appreciate that everyone's busy and kindly volunteers their time to work on MP. That applies to myself as well though and it does take considerable time to keep making debug logs, screenshots, documenting issues and posting them. It would be much easier and less stressful for me not to bother and put up with or work around the issues but I'm trying to help make MP more user-friendly for new users so they won't be put off it.

It does actually take quite a bit of time to understand what MP requires in terms of tags and then go through a collection ensuring that everything is correct (as you seem to know anyway by your earlier statement "I have spent a great deal of time ensuring that my music is correctly tagged"). Obviously some of this is unavoidable for the various views to work properly, but if the amount of work needed can be minimised and unnecessary work eliminated this seems to be sensible.

As I've said, I'm quite willing to accept that changing things as per my suggestion may cause problems for others, or may just be considered too much work or not high-priority enough, but you haven't given me an example of how it would cause problems for others or, as far as I can tell, properly understood or assessed the potential benefits from my suggestion (mainly, reducing the amount of time users need to spend checking and correcting their tags).

Ultimately, the code is available, so if you want to try to understand it and fix it to work the way you want, there is nothing stopping you doing this. Personally I don't have the ability to do this, so it is easier for me to tag my music so that it works.

Like you, I don't have the ability to understand or rewrite the code, so my contribution is to try and make helpful suggestions. I could of course spend the time tagging my tracks to suit MP as you have done, but if it's possible to do something to reduce the amount of time users need to spend doing that, it would be preferable. I don't believe you meant it like this, but what you've said suggests that if users can't code, rather than offer suggestions to make things easier they should just spend their time doing whatever they need to, to workaround whatever issues they encounter.

 

[elliottmc]

Re: Album view: looks at other fields in MP3s with blank Album, creates multiple fold

Again I don't believe it's fair to characterise my input as "arguing". I explained why I thought it would be better if tracks with no Album data were all grouped in one folder,

But this is the point you are missing. The tracks DO have album data (assuming I am not misinterpreting you). They have something in the albumartist tag. They have track numbers (possibly) and discnumbers.

Album data does not simply refer to having something in the 'album' tag.

To reiterate my point, for the final time, mp3 tracks with only the song title and artist are grouped in album view exactly as you want them. Personally I am not convinced this is the expected behaviour, although it is probably more hassle than it is worth to check for an empty string and not display anything at all.

We are spending so much time on this non-issue that we are losing time that could be used to identify actual bugs.

Mark