"the" items (artists, albums, songs?)

understood. it will not change the label of the item, just remove prefixes for sorting purposes.

yes, while i agree that a regexp would work, i think its unnecessary complexity. a simple pipe seperated string would suffice. it shouldnt need to do any fancy transformations, just remove certain starting words. i had an idea on how this would work and would be more than happy to share it with you.

btw, ([the ]) would not do what you wanted. the correct regexp is ^(the ).

your original regexp would potentially remove all t's, h's, e's and spaces. see what i mean about complexity? do we want to give users the ability to arbitrarily remove the second character with ^.(.) ?

edit... fixed some typos... its hard to type this stuff while im *supposed* to be working

ha, tell me about it!

just don't tell my boss...

ok, sorry, i should have said "pseudo-regexp", obviously wasn't going for accuracy. yeah i agree that it is more complex, but...

isn't it exactly the same issue we have in other places, i.e. stacking? i was on vacation for a few weeks while the stacking was changed to regexp, but when i came back, after i checked it out and started using it, i liked it. before that, stacking was just like what you are talking about - a pipe-delimited list of possible suffixes.

the main reason that regexp had to be introduced for stacking was due to the wide variety of file names that come in from various "sources" out there. i know your philosophy is that users should be responsible for renaming all of their files (and personally, i do) - but introducing the regexp definitely opened the doors to many more users to be able to use stacking without having to mess around with understanding how it works under the covers.

given that we are now essentially talking about a natural language problem, the potential for complexity seems even larger - before it was just the limited variety of file-naming formats for volume numbers - now we are talking about something that may need to be flexible enough to handle many complex natural language scenarios that we can't possibly imagine.

even though it introduced some problems initially, i think the strategy we've taken with stacking is working well now - basically, establish a good base set of regexp expressions that suit the needs of most users, and make sure those work well for most files. then on the exceptional cases, offer assistance.

again, agreed that this leads to more complexity, and not quite convinced myself one way or another. but i'm pretty sure that if we don't use regexp now, we'll regret it later.

this is a really good discussion about how to handle file names and i would like to make a suggestion.  i would like there to be a sortname field in the mymovie db.  the reasoning for this is that i like to have sequels displayed in order (rocky i, rocky ii, etc), but movies like lord of the rings gives problems since the movies aren't numbered and sorting alphabetically leaves them in the wrong order.  this would also give free reign to any kind of sorting a user would want (including ignoring "the", "a", "an", or whatever).

maybe the best solution would be to use a settings option (on/off) along with the regexp or pipes for files view only.  then any changes that would be desired for title view users could be done by simply editing the sortname field in the db.  this would minimize the number of options for the user and provide more flexibility to those who use title view.

just my $0.02

gglaze,
it was necessary for stacking because it was the only way to describe where the volume descriptor was located. in this case, you should only be truncating characters from the front of a string (aka prefixes). what more do you need to do?

rockdawg,
this is a little different thing but yes this has brought up before, and it it will be added to the video database. there are some other changes to the video database coming soon so i want to bundle them all together. the "sortname" will be a hidden column in the database that advanced users will be able to take advantage of.

just curious.  why have sortname be hidden and how advanced will a user need to be?

any word on what some of the other changes will be, or should i just wait and see?

edit: i almost forgot... thanks a ton for adding the sortname field! now, if we could just get a seperate db for tv shows all would be right with the world.

there was another discussion on sortname, brought about by tomkun iirc. search for it. the consensus was to make it hidden. you would need to open the db on your computer and fill in the field for those movies which need it. (the indy series was the example used in the thread.)

mercury was working on something that allows a user to flag a movie was "watched" which would be used to filter the display list. since db changes require a db upgrade, i was going to bundle adding this new field in with that.

a little later on, the video db windows will become a video library window like the music. there was a seperate discussion on that as well. (unlike the music database, it will likely not be a multi-tiered filtering system.)

yes, i posted in that thread, but i didn't see your last post saying you may implement it. also, i misunderstood what you meant by hidden. in this thread i suggested using a sortname field and editting the db so when you said "hidden" and for advanced users, i thought you meant hidden in the db and for advanced db users. now, i see you mean hidden as in not displayed in xbmc and advanced as in needing to edit the db. gotcha now. sorry for the brain fart.

the "watched" tag sounds great too. that was another feature i missed coming over from meedio. i had seen the patch for it, but since i don't compile my own builds (use t3ch builds) i wasn't able to have it.

i'll have to check out the music library view (and that thread if i can find it). currently i mostly use the files there. either way, it sounds like it will only make things nicer. great job to all you devs!

sorry to have drug this off topic.

i just wanted to say that i think it would be great if sorting without "the" could be implemented in file view, even if it is in some xml file. that is fine by me.

i'll just say that the reason i don't like the library view is that unlike music i can't change the metadata on my video files. i've gone through and custom edited the id3 tags on all of my music (16,000+ tracks... that took forever :bomb: ), but i can't do this with my video files, i have to rely on the imdb (which is especially terrible for stuff like tv shows). as a result i want to sort things manually via file view (and thus organize tv shows in folders, etc), but i also want the niceites of library sorting (like leaving out the "the"). so, i guess you could say that i want to have my cake and eat it too (what the hell else is the point of cake, anyway?).

anyway, i would be super fantastic happy if ignoring "the" could be implemented for file view, even if it isn't in the gui, and i think that there is enough of a contingent of other users that would agree with me to make this a desireable feature.

thanks

i agree completely with noumenon's post above. i used an older version of xbmc before the "ignoring "the"" was excluded in file view and now i really miss that function. for the same reasons noumenon gave i think it would be great if this could once again be implemented for file view (although i understand the points brought forth by kragh3d). to make it optional solves the issues for all of us and would make me (and noumenon) very happy . whether it would be in the gui or xml doesn't matter.

about ignoring "a" when sorting, i personally don't think it should be ignored in the sorting, but i'm sure someone would disagree. however, being able to sort for example rocky, rocky 2 etc. in the right order would be a nice feature too. but that would just be icing on the (aforementioned) cake.

i just want to stress once again that this feature is really missed! i actually signed up for the forum just to make this comment. keep up the good work with xbmc! it's appriciated!

thank you
/the duke