[Harry Muscle]

@jmarshall
Thanks for clarification. I wasn't sure as I'm managing my media with EmberMM since quite some time now and didn't remember XBMCs behavior from the time before EmberMM.

The patch is gonna bring the skins behaviour of looking for dvd, bluray, etc. into the actual XBMC code ... btw, the patch is basically done, just a few minor touch ups tomorrow and it should be up on the trac waiting for approval.

@Harry Muscle
As for the file suffix, I'd still go the way to use the suffix ".offline" for it I think and add the parser for the strings "dvd/bluray/brd/hddvd" to the "default" file parser of XBMC (if something like this exists). Maybe you have to implement it at the same place anyway.

Unfortunately I'd have to disagree with the .offline extension. Offline files are those that aren't there ... the official term for the kind of support that I'm adding is stub files. Files that are there (therefore not offline) but represent another media (ie: DVD, Bluray, etc.). We also need to differenciate between which type of media is represents, since for example for HDDVD there's no point in asking the user to put in the disc since XBMC can't play them anyway. There's a decent amount of demand for offline file support and I really don't want this patch to step into that field ... it's totally different, although technically it can be used to accomplish the same thing.

And I don't think you should use stuff like "movie-title.disc-123.dvd" for the label support, due to the fact that XBMC might think that those files could be a stack as it's already looking for "disc[0-9]*" IIRC. So better find a approach/spelling that's not yet in use and allows any disc label - not just numbers - like my proposal with the "#" prefix: "movie-title.#any-label.dvd.offline"

That's a very good point about the stacking ... didn't think of that. I've got another idea ... I'll post it seperately to keep things more clear.

Slightly OT:
It'll be cool if one could hook into the file parser of XBMC and add custom parsing rules and perform actions based on them, so that the offline support could become a addon with a more frequent release cycle. Not sure if you guys are familiar with hooks, so I'll try to explain: Hooks are pretty much like events - so a addon would have to register itself to a hook/event of a certain process. Those processes explicitly need to support hooks/events of course, so they need to check if there are registered listeners/hook-methods and call one after another by passing n parameters to the registered addon methods. I know this hook concept from PHP frameworks and it's a nice way to extend tools. Maybe that's already possible somehow - I'm unfortunately not (yet) familiar with C++ and was totally lost when I had a look at the source code of XBMC (it's not the syntax, but more a question of getting used to the partly cryptic variable names, find out where to start looking and find out how stuff is interacting with eachother).

No comment on that one

Thanks,
Harry