View Issue Details

IDProjectCategoryView StatusLast Update
0000132MediaMonkey 4Main Panel/Toolbars/Menuspublic2009-02-06 00:14
Reporterrusty Assigned To 
PriorityurgentSeverityminorReproducibilityalways
Status closedResolutionfixed 
Fixed in Version3.1 
Summary0000132: Numbers in Track Titles are Confusing
DescriptionWhen the user rips a CD using a mask of <artist> - <title>, and then looks at the ripped album in the database, the title is listed as <Track#>.<title>. This makes it appear as though the conversion mask didn't work, and the user then tries to edit the title so that it conforms to the tag structure that they use.

If I remove the CD from the drive and refresh the tree, it still doesn't correct the problem--the only way to solve it is to close the app and then restart it without the CD--then the numbers get removed from the title, but soon after it re-appears--almost as if another _different_ mask is being applied to it!!

This is very confusing for the user, and we often receive questions about why the track# is part of the title (in the Now Playing, Playlist, and Album nodes).
TagsNo tags attached.
Fixed in build1185

Relationships

related to 0004012 closedpetr Title appends Track# in Album Nodes (regression) 
related to 0004874 closedpetr Play Order ('#' column) Sorting doesn't work correctly 
related to 0005016 closedpetr Track order display should be configurable 

Activities

rusty

2003-02-24 15:00

administrator   ~0000281

Last edited: 2003-02-25 15:32

Re-assigning to Rusty to figure out exact repro steps--it doesn't seem to occur consistently.

edited on: 02-25 10:32

rusty

2003-03-12 16:21

administrator   ~0000451

OK, I now know what's going on here. There is a feature in Songs-DB that makes the user think that track-order is included in the Title. To be specific:
-When the user clicks any _album_ in the tree, if the track order field isn't empty, the Title of the song in the listview is shown as "%track#%. %title%".
-When the user clicks the _now playing_ node or any particular _playlist_ node, something similar occurs: the Title of the song in the listview is shown as "%play_order%. %title%".

In all three cases, it appears to the user as if the file has somehow been renamed (even though this is just a display artifact)! It's especially confusing because then if the user clicks the song in a different node, the title is magically modified (e.g. in the Artist node, the prefix is eliminated).

An easy way to resolve this would be to:
-By default, make the track order column appear first (for all nodes but the 'special' now playing and playlist nodes. Also, eliminate the special prefixes that are currently used with Album subnodes.
-By default, in the now playing and playlist nodes, and a column indicating '#' or 'order' so that it is clear that the song title hasn't been modified.

jiri

2003-03-13 08:46

administrator   ~0000471

I understand that the current solution is somewhat confusing, but on the other hand I am not sure if there exists a better solution. E.g. in that what you proposed:
 - Column order would need to be different in playlists and other nodes (currently only Playing now is special)
 - In other than Album nodes the track order isn't important and is actually confusing (in many nodes it would result in a random list of numbers)

rusty

2003-03-17 16:42

administrator   ~0000521

Let me clarify the current situation and an updated proposed solution:

Currently there are _3_ special cases (that I'm aware of):
1) When the user selects an album the following appears:
 -All properties that normally appear for a song
 -Under the title property: t. title appears (where t=track#)
2) When the user selects a playlist, the following appears:
 -All properties that normally appear for a song
 -Under the title property: p. title appears (where p=playlist_order#)
3) When the user selects the now playing node or dialog, the following appears:
 -The headings Title, Artist, Length
 -Under the title property: n. title appears (where n=now_playing_order#)

The problems here are that in all three cases it is unclear what the actual title is. Also, the distinction between track# and play order is unclear.

A solution that would deal with the bug _and_ the issues you raised would be:
1) For album nodes, add an obligatory 'Track#' column to the left of the title column (this can be abbreviated to '#' for formatting purposes)
2) In the playlist node, add an obligatory 'Order' Column to the left of the title. This will have the play order.
3) In the now playing node, add an obligatory 'Order' column to the left of the title. This will reflect the play order.
4) To clearly distinguish between play order and Track #, all instances in the UI of Track #, should be clearly identified as such.

jiri

2003-03-18 12:16

administrator   ~0000545

It is possible to implement it this way. These columns will only occupy some more space, but that's quite ok. I would just change severity to minor and priority to normal (it is problem, but not too big). Do it as you wish.

rusty

2003-03-18 17:15

administrator   ~0000555

Agreed.

rusty

2003-10-31 04:13

administrator   ~0002703

Note: another possibility is to simply eliminate the t.#

rusty

2004-01-26 02:38

administrator   ~0002883

pushedfrom22

rusty

2004-08-04 03:09

administrator   ~0004437

Here's a nice thread describing the problem: http://www.songs-db.com/forum/viewtopic.php?t=2152

jiri

2007-03-27 09:01

administrator   ~0008898

I wonder whether we couldn't fix this issue while retaining the current functionality. I'd like to do so, because although sometimes users complain about it, it seems to work well for many and from my point of view it is aesthetically better than forcing showing of Track # column.

My idea is to fix the issue by showing the # in different font, probably the standard disabled/non-editable which means light gray color by default. So it would look like: <gray>3.</gray> <black>Track title</black> and thus it would clearly indicate that the # isn't part of the title.

Also another sub-issue should be fixed: Currently the # is always shown in Title column, but is should be rather shown in the very first column (which can be different if user reorders them). In a very unlikely event that user makes the first column some of the right-aligned ones (i.e. numeric), the number wouldn't be shown at all, because it would probably look weird.

rusty

2007-03-27 15:10

administrator   ~0008903

I like your idea of giving users the ability to include play order for playlists and Now Playing views/nodes, but not for Album nodes.

So in the Now Playing and Playlist nodes/views, there could be a new column header '#', as you describe for play order.

In the Album Views, though, Track# should be positioned as the first column header (play order isn't really relevant for Album nodes).

jiri

2007-03-27 15:27

administrator   ~0008904

I probably wasn't clear, I would like to avoid adding a new column '#', it would look like:

Title | Artist | ....
-------------------------
1.xxx | yyy | ....

or (if columns are reordered)

Artist | Title | ....
-------------------------
1.yyy | xxx | ....

Just that '1.' would be light gray instead of black color (that's what I meant by the example: <gray>3.</gray> <black>Track title</black>)

Re. Album views - I'd prefer to keep the numbers there as well, although it probably isn't absolutely necessary. Or, we could possibly make it optional in this case. Maybe we could ask in the forum to get some feedback about how users like it...

rusty

2007-03-27 15:52

administrator   ~0008907

I just don't understand the advantage of the approach you're proposing.

For Playlists and Now Playing nodes, it only partially solves the problem (sort order is still ambiguous--does it sort by title or sort by play order), and for Album nodes, it just duplicates information that is already in the library.

jiri

2007-04-19 13:35

administrator   ~0009055

Ok, let's add a new column. Just in order to confirm that it won't cause any problems I added a poll to http://www.mediamonkey.com/forum/viewtopic.php?t=17184 .

jiri

2007-04-30 17:02

administrator   ~0009086

Ok, so it seems to be clear that users don't have any significant problem with the proposed change. So let's use the solution proposed above:

1) For album nodes, add a obligatory 'Track#' column to the left of the title column (this can be abbreviated to '#' for formatting purposes).
2) In the playlist node, add an obligatory 'Order' Column to the left of the title. This will have the play order.
3) In the now playing node, add an obligatory 'Order' column to the left of the title. This will reflect the play order.
4) To clearly distinguish between play order and Track #, all instances in the UI of Track #, should be clearly identified as such.
5) All nodes would still share the same position and size of columns, '#' columns would be just always shown as the first column for the specified nodes. Position of this column wouldn't be saved - but it would be for other columns.

rusty

2007-08-23 21:31

administrator   ~0010289

Note:

Re. 4) 'Order #' in Now Playing and Playlist can be shortened to '#'. To limit the chance that users will confuse it with actual metadata, it might be worth displaying it as a greyed out number (or in some other color) so that it's clear that it's not actual metadata.

rusty

2007-11-27 03:51

administrator   ~0012187

Note: when we fix this we should also make sure to remove the 'feature' that causes MM to modify track# when the prefix appears e.g. as '1. ', as described in bug 0004012.

petr

2008-08-21 21:53

developer   ~0014462

Will be implemented in 1185

stephen_platt

2008-12-05 03:50

developer   ~0015408

Verified 1199

Owyn

2008-12-05 20:26

updater   ~0015430

Discussion in forum about whether the # column should be completely hide-able.
http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=34728

rusty

2008-12-09 14:07

administrator   ~0015560

Last edited: 2008-12-09 14:08

Resolving and moving discussion to 0005016 for tweaks re. # column configurability and limiting to NP/Playlists (so that this issue will have a separate item in the changelog).