Android is Case Sensitive splitting values
Moderator: Gurus
Android is Case Sensitive splitting values
Minor thing:
E.g. "Rap DE" and "Rap De" are listed separately. This does not happen on MMW.
Update: same happens with Album Artist. E.g. "of" and "Of".
Also changed cases in any metadata do not get updated when changed on MMW.
Update 2: As I already made so many new posts today, I add this here. It's minor too but: Album Artists listing sometimes only show album count, and track count is missing.
E.g. "Rap DE" and "Rap De" are listed separately. This does not happen on MMW.
Update: same happens with Album Artist. E.g. "of" and "Of".
Also changed cases in any metadata do not get updated when changed on MMW.
Update 2: As I already made so many new posts today, I add this here. It's minor too but: Album Artists listing sometimes only show album count, and track count is missing.
Re: Genre listing is case sensitive
We're probably going to fix this on the MMW side. See:
http://www.ventismedia.com/mantis/view.php?id=11516
-Russell
http://www.ventismedia.com/mantis/view.php?id=11516
-Russell
Re: Genre listing is case sensitive
Be aware this results in the different cases of a genre showing up as SEPARATE genres (eg MMA shows BOTH "Folk Rock" and "Folk rock" as 2 distinct genres, with different sets of tracks).
Environment:
MMW: ~25,000 tracks, MM.DB on 16Gbps PCIe SSD (Samsung 950 Pro) - up-to-date, not Beta
MMA: ~12,000 tracks sync'd to phone - up-to-date, not Beta
PC: Windows 10/64, Skylake quad+HT @4.2GHz, 64GB RAM, 14TB RAID6
Phone: Galaxy S10 (128GB) + 400GB mSD card (Samsung EVO+)
Sync: all tracks rated >=3 sync'd to phone
.........all playlists only use tracks rated >=3
.........thus sync'ing is 99.99% playlist update - no tracks are sync'd, other than new purchases
Playlists: ~59 synced
..........most are auto-playlists
..........use attributes Rating, Last Played, Date recorded, Genre, Genre "contains", Path "contains"
..........many are nested, i.e. "Top AutoPlaylist" includes "Level 2 AutoPL #1" + "Level 2 AutoPL #2" etc.
MMW: ~25,000 tracks, MM.DB on 16Gbps PCIe SSD (Samsung 950 Pro) - up-to-date, not Beta
MMA: ~12,000 tracks sync'd to phone - up-to-date, not Beta
PC: Windows 10/64, Skylake quad+HT @4.2GHz, 64GB RAM, 14TB RAID6
Phone: Galaxy S10 (128GB) + 400GB mSD card (Samsung EVO+)
Sync: all tracks rated >=3 sync'd to phone
.........all playlists only use tracks rated >=3
.........thus sync'ing is 99.99% playlist update - no tracks are sync'd, other than new purchases
Playlists: ~59 synced
..........most are auto-playlists
..........use attributes Rating, Last Played, Date recorded, Genre, Genre "contains", Path "contains"
..........many are nested, i.e. "Top AutoPlaylist" includes "Level 2 AutoPL #1" + "Level 2 AutoPL #2" etc.
Re: Genre listing is case sensitive
I read the comments in the bug tracking system...
I do NOT agree that Rock and RocK should be separate genres - unless someone can explain to me what the difference is between those 2 genres? Or is it just a computer/Unix viewpoint?
Genres are logical categories, not really proper nouns, and thus the *intention* is that they refer to the same concept. If there's an Artist named John vs jOHN, then those are more likely truly different, as they are full-on proper nouns. Bur what about English vs. American spelling of genres (color vs colour, etc.) - are those really different? Mix that with case, and we're really in trouble.
I can still see many people preferring case typos being fixed in their 37 Beatles albums, over the one oddball artist name being cased correctly.
We already have too much proliferation and confusion about Genres vs. styles that we're approaching 1 genre for every track - let's not make the matter worse.
I do NOT agree that Rock and RocK should be separate genres - unless someone can explain to me what the difference is between those 2 genres? Or is it just a computer/Unix viewpoint?
Genres are logical categories, not really proper nouns, and thus the *intention* is that they refer to the same concept. If there's an Artist named John vs jOHN, then those are more likely truly different, as they are full-on proper nouns. Bur what about English vs. American spelling of genres (color vs colour, etc.) - are those really different? Mix that with case, and we're really in trouble.
I can still see many people preferring case typos being fixed in their 37 Beatles albums, over the one oddball artist name being cased correctly.
We already have too much proliferation and confusion about Genres vs. styles that we're approaching 1 genre for every track - let's not make the matter worse.
Environment:
MMW: ~25,000 tracks, MM.DB on 16Gbps PCIe SSD (Samsung 950 Pro) - up-to-date, not Beta
MMA: ~12,000 tracks sync'd to phone - up-to-date, not Beta
PC: Windows 10/64, Skylake quad+HT @4.2GHz, 64GB RAM, 14TB RAID6
Phone: Galaxy S10 (128GB) + 400GB mSD card (Samsung EVO+)
Sync: all tracks rated >=3 sync'd to phone
.........all playlists only use tracks rated >=3
.........thus sync'ing is 99.99% playlist update - no tracks are sync'd, other than new purchases
Playlists: ~59 synced
..........most are auto-playlists
..........use attributes Rating, Last Played, Date recorded, Genre, Genre "contains", Path "contains"
..........many are nested, i.e. "Top AutoPlaylist" includes "Level 2 AutoPL #1" + "Level 2 AutoPL #2" etc.
MMW: ~25,000 tracks, MM.DB on 16Gbps PCIe SSD (Samsung 950 Pro) - up-to-date, not Beta
MMA: ~12,000 tracks sync'd to phone - up-to-date, not Beta
PC: Windows 10/64, Skylake quad+HT @4.2GHz, 64GB RAM, 14TB RAID6
Phone: Galaxy S10 (128GB) + 400GB mSD card (Samsung EVO+)
Sync: all tracks rated >=3 sync'd to phone
.........all playlists only use tracks rated >=3
.........thus sync'ing is 99.99% playlist update - no tracks are sync'd, other than new purchases
Playlists: ~59 synced
..........most are auto-playlists
..........use attributes Rating, Last Played, Date recorded, Genre, Genre "contains", Path "contains"
..........many are nested, i.e. "Top AutoPlaylist" includes "Level 2 AutoPL #1" + "Level 2 AutoPL #2" etc.
Re: Genre listing is case sensitive
Toyzrme .. i have to agree. The genre Rock and ROck should be sorted to same. Genre should be case-insensitive.toyzrme wrote:I read the comments in the bug tracking system...
I do NOT agree that Rock and RocK should be separate genres - unless someone can explain to me what the difference is between those 2 genres? Or is it just a computer/Unix viewpoint?
Genres are logical categories, not really proper nouns, and thus the *intention* is that they refer to the same concept. If there's an Artist named John vs jOHN, then those are more likely truly different, as they are full-on proper nouns. Bur what about English vs. American spelling of genres (color vs colour, etc.) - are those really different? Mix that with case, and we're really in trouble.
I can still see many people preferring case typos being fixed in their 37 Beatles albums, over the one oddball artist name being cased correctly.
We already have too much proliferation and confusion about Genres vs. styles that we're approaching 1 genre for every track - let's not make the matter worse.
Where's the db and ini stored
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Re: Genre listing is case sensitive
Playing devils advocate:
Why should errors in the metadata should be hidden? All it does it perpetuate them so that the user may not see them in MM, but will see them when viewed in other apps. From my perspective it makes more sense to provide tools to help the user correct them.
You might make the argument that the metadata can appear with its errors (e.g. in the properties dialog), but that when browsing e.g. via the Artists or Genres node, it should be hidden. But from my perspective that just results in confusion ("why is 'ACDC' displayed in the tree, but 'acdc' displayed in the metadata?").
-Rusty
Why should errors in the metadata should be hidden? All it does it perpetuate them so that the user may not see them in MM, but will see them when viewed in other apps. From my perspective it makes more sense to provide tools to help the user correct them.
You might make the argument that the metadata can appear with its errors (e.g. in the properties dialog), but that when browsing e.g. via the Artists or Genres node, it should be hidden. But from my perspective that just results in confusion ("why is 'ACDC' displayed in the tree, but 'acdc' displayed in the metadata?").
-Rusty
Re: Genre listing is case sensitive
I have a similar sentiment, but MMW won't show separate entries for each case in the Media Tree. So MMA showing separate entries isn't consistent with the experience on MMW. I also guess that for most MMA will be more for playback then editing and the separate entries would get in the way of that experience.Rusty wrote:Why should errors in the metadata should be hidden? All it does it perpetuate them so that the user may not see them in MM, but will see them when viewed in other apps.
Download MediaMonkey | License
Help: Knowledge Base | MediaMonkey for Windows 5 | MediaMonkey for Android
Lowlander (MediaMonkey user since 2003)
Help: Knowledge Base | MediaMonkey for Windows 5 | MediaMonkey for Android
Lowlander (MediaMonkey user since 2003)
-
- Posts: 23640
- Joined: Wed Aug 09, 2006 10:20 am
- Location: NJ, USA
- Contact:
Re: Genre listing is case sensitive
Agreed. If anything, the behaviors should be reversed, so MMW shows case differences in the tree but not in MMA.Lowlander wrote:I have a similar sentiment, but MMW won't show separate entries for each case in the Media Tree. So MMA showing separate entries isn't consistent with the experience on MMW. I also guess that for most MMA will be more for playback then editing and the separate entries would get in the way of that experience.
MediaMonkey user since 2006
Need help? Got a suggestion? Can't find something?
Please no PMs in reply to a post. Just reply in the thread.
Need help? Got a suggestion? Can't find something?
Please no PMs in reply to a post. Just reply in the thread.
Re: Genre listing is case sensitive
I wasn't suggesting that mmw or mma should show Rock even if there is a Rock, ROck or ROCK. What I was suggesting is that the SORT of these items should be case-insensitive. THEN show them all together. Sorry if my comment caused any confusion.
Where's the db and ini stored
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Re: Genre listing is case sensitive
Good discussion - all the above makes sense.
I agree with Rusty, in that HIDING errors is bad. But MMW & MMA need to be consistent between them. Or, if anything, differences shown in the *editing* tool (MMW), but NOT in the *playback* tool (MMA) (as nohitter151 suggests).
As for displaying, an issue that can happen: given a few "close" genres, say Rock/Hard, Rock/Soft, etc, if the sorting is purely character/numerical, then case variants will produce something like the following, making it harder to spot the problems:
ROCK/HARD
ROCK/SOFT
ROck/Hard
ROck/Soft
Rock/Hard
Rock/Soft
Tossing out a few ideas off the top of my head:
- let the user choose whether to treat a given field as case-sensitive or not?
This would be a bit of a coding effort, even for 1 field, as it affects sorting, querying, display, playlists, tooling, etc, etc.
But code is free on the Forums, right? (ahem)
- do BOTH? Make them BEHAVE as if the same, but SHOW the user that both exist.
This is similar to nohitter151's idea in some ways, ie MMA=behave the same, MMW=show differences,
and in line with what dtsig is suggesting for MMW: SORT them so that they show up together, but still preserve the distinction.
Maybe some highlighting here could help (ie if multiple items have the same value ignoring case, show them all, but highlight the field(s) in question)
Tooling could also help here: for each entry, see how many matches there are for it both case-sensitive and insensitive - if they differ, highlight the item (I wouldn't be surprised if someone has already done this - trixmoto?)
One more suggestion: can I please have a way to define a genre hierarchy?
That way, I could create a "Rock/Hard" parent, and put the variants below it, but define all my queries/playlists using the parent (unless I *really* only want Rock/Hard/Tribal/from-some-small-CarribbeanIslandThatBeginsWith-"Saint")
(yes, this is my evil, subversive plot to squash 561 genres in my library into a few simple categories for my poor feeble brain to handle while playing on my phone - like Rock, Jazz, Classical, New Age, maybe Vocal/Acapella)
I agree with Rusty, in that HIDING errors is bad. But MMW & MMA need to be consistent between them. Or, if anything, differences shown in the *editing* tool (MMW), but NOT in the *playback* tool (MMA) (as nohitter151 suggests).
As for displaying, an issue that can happen: given a few "close" genres, say Rock/Hard, Rock/Soft, etc, if the sorting is purely character/numerical, then case variants will produce something like the following, making it harder to spot the problems:
ROCK/HARD
ROCK/SOFT
ROck/Hard
ROck/Soft
Rock/Hard
Rock/Soft
Tossing out a few ideas off the top of my head:
- let the user choose whether to treat a given field as case-sensitive or not?
This would be a bit of a coding effort, even for 1 field, as it affects sorting, querying, display, playlists, tooling, etc, etc.
But code is free on the Forums, right? (ahem)
- do BOTH? Make them BEHAVE as if the same, but SHOW the user that both exist.
This is similar to nohitter151's idea in some ways, ie MMA=behave the same, MMW=show differences,
and in line with what dtsig is suggesting for MMW: SORT them so that they show up together, but still preserve the distinction.
Maybe some highlighting here could help (ie if multiple items have the same value ignoring case, show them all, but highlight the field(s) in question)
Tooling could also help here: for each entry, see how many matches there are for it both case-sensitive and insensitive - if they differ, highlight the item (I wouldn't be surprised if someone has already done this - trixmoto?)
One more suggestion: can I please have a way to define a genre hierarchy?
That way, I could create a "Rock/Hard" parent, and put the variants below it, but define all my queries/playlists using the parent (unless I *really* only want Rock/Hard/Tribal/from-some-small-CarribbeanIslandThatBeginsWith-"Saint")
(yes, this is my evil, subversive plot to squash 561 genres in my library into a few simple categories for my poor feeble brain to handle while playing on my phone - like Rock, Jazz, Classical, New Age, maybe Vocal/Acapella)
Last edited by toyzrme on Sat Dec 13, 2014 4:13 pm, edited 1 time in total.
Environment:
MMW: ~25,000 tracks, MM.DB on 16Gbps PCIe SSD (Samsung 950 Pro) - up-to-date, not Beta
MMA: ~12,000 tracks sync'd to phone - up-to-date, not Beta
PC: Windows 10/64, Skylake quad+HT @4.2GHz, 64GB RAM, 14TB RAID6
Phone: Galaxy S10 (128GB) + 400GB mSD card (Samsung EVO+)
Sync: all tracks rated >=3 sync'd to phone
.........all playlists only use tracks rated >=3
.........thus sync'ing is 99.99% playlist update - no tracks are sync'd, other than new purchases
Playlists: ~59 synced
..........most are auto-playlists
..........use attributes Rating, Last Played, Date recorded, Genre, Genre "contains", Path "contains"
..........many are nested, i.e. "Top AutoPlaylist" includes "Level 2 AutoPL #1" + "Level 2 AutoPL #2" etc.
MMW: ~25,000 tracks, MM.DB on 16Gbps PCIe SSD (Samsung 950 Pro) - up-to-date, not Beta
MMA: ~12,000 tracks sync'd to phone - up-to-date, not Beta
PC: Windows 10/64, Skylake quad+HT @4.2GHz, 64GB RAM, 14TB RAID6
Phone: Galaxy S10 (128GB) + 400GB mSD card (Samsung EVO+)
Sync: all tracks rated >=3 sync'd to phone
.........all playlists only use tracks rated >=3
.........thus sync'ing is 99.99% playlist update - no tracks are sync'd, other than new purchases
Playlists: ~59 synced
..........most are auto-playlists
..........use attributes Rating, Last Played, Date recorded, Genre, Genre "contains", Path "contains"
..........many are nested, i.e. "Top AutoPlaylist" includes "Level 2 AutoPL #1" + "Level 2 AutoPL #2" etc.
Re: Genre listing is case sensitive
Thanks for all the feedback--we're not ignoring you...just deferring examination of this issue until after 1.0.4 is released.
-Rusty
-Rusty
Re: Genre listing is case sensitive
Just following up/am curious. There is currently no way for users to manually correct this on MMA, correct?
Re: Genre listing is case sensitive
My Tagging Inconsistencies script, link in signature, can find these in MMW. Use the "Node vs Track Case Inconsistencies"-node which exists for Genres, Artists and Albums.
Advanced Duplicate Find & Fix Find More From Same - Custom Search. | Transfer PlayStat & Copy-Paste Tags/AlbumArt between any tracks.
Tagging Inconsistencies Do you think you have your tags in order? Think again...
Play History & Stats Node Like having your Last-FM account stored locally, but more advanced.
Case & Leading Zero Fixer Works on filenames too!
All My Scripts
Tagging Inconsistencies Do you think you have your tags in order? Think again...
Play History & Stats Node Like having your Last-FM account stored locally, but more advanced.
Case & Leading Zero Fixer Works on filenames too!
All My Scripts
Re: Genre listing is case sensitive
This reminded me that I had problems with case for searching too. Which I assume is connected.
I searched for "lorde" and got nothing, although I knew I had an album by her on there. Which confused me. On a whim I tried searching for "Lorde" and it came up.
Given the hassle that text entry can be on a touch interface, I think search should definitely be case insensitive.
RE: the rest of this thread: I'd also say that genre, album, artist, etc.. should be case insensitive too.
I kinda get the argument about not hiding people's errors... but not really. I want the software to be smart and help me out and minimise the work/hassle on my end, not be awkward just to point out minor insignificant mistakes. Particularly on a mobile device which will be used 99% for quick playback on the go, and not for editing libraries.
I searched for "lorde" and got nothing, although I knew I had an album by her on there. Which confused me. On a whim I tried searching for "Lorde" and it came up.
Given the hassle that text entry can be on a touch interface, I think search should definitely be case insensitive.
RE: the rest of this thread: I'd also say that genre, album, artist, etc.. should be case insensitive too.
I kinda get the argument about not hiding people's errors... but not really. I want the software to be smart and help me out and minimise the work/hassle on my end, not be awkward just to point out minor insignificant mistakes. Particularly on a mobile device which will be used 99% for quick playback on the go, and not for editing libraries.
Re: Genre listing is case sensitive
When I search on Artist/Album Artist/Title/Album it seems to be case insensitive. Tested no build 236.
If that's not the case for you, can you provide a bit more detail (e.g. device, android version, MMA version, does this always happen?).
Thanks.
-Rusty
If that's not the case for you, can you provide a bit more detail (e.g. device, android version, MMA version, does this always happen?).
Thanks.
-Rusty