Kodi Community Forum
Indexing and flagging offline removable DVD Video discs in the library database? - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: Indexing and flagging offline removable DVD Video discs in the library database? (/showthread.php?tid=24443)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13


- pecinko - 2010-09-26

da-anda Wrote:I'm not sure how to handle situations with multiple video files on one disc. I'm not even sure how to index that. I think you would need a offline file for each movie and the name of the offline file would have to match the filename on the disk.

As far as XBMC can distinct name, they can be added as 2 separate movies it does not matter that they would be on same disc. Situation gets complicated when XBMC tries to play them as it should do string comparison in order to choose right one (DB vs file name on disc).

It would be easier if could be agreed that 1 disc = one movie title.

And you're right, music should be scratched.


- pecinko - 2010-09-26

Harry Muscle Wrote:You need a standardized extension of some sorts so that XBMC can know what kind of offline media you are talking about (to show the correct codec information in the skin).

If extension = all digits, assume offline media, use digits as offline DISC number?

EDIT: Better (safer) way:

If file size = 0, assume offline media, use digits from extension as offline DISC number.


- Harry Muscle - 2010-09-27

I'll see what I can do about disc number support once all the rest of the work is done. But I think the best and most consistent way to deal with disc number support is similar to how Season Episode support is done for TV shows ... scan for the word disc and the number after that word, or other similar combinations, just like we scan for the word Season followed by a number and such. So a file that specifies Finding Nemo on DVD that's part of your custom disc number system (for example disc 44) could be:

Finding Nemo (2003) - Disc 44.dvd

or maybe

Finding Nemo (2003) - D44.dvd

etc.

We'd make sure the file is zero size too.

Thanks,
Harry


- Harry Muscle - 2010-09-27

da-anda Wrote:Hey there. After thinking about it again, we don't need any of those. We would just need support for a ".offline" suffix. Reason is, that XBMC is already parsing the filename for strings like "bluray", "dvd", "hddvd" etc, right? So names like "batman begins.bluray.offline" would work just fine.

The only thing we might find a nice way to implement would be the disc name support within the filename if not present in a .nfo file. My proposal would be the following: "MyPrivateMovies.dvd.#movies1.offline"
So prefixing the disc name with a #.

What do you guys think?

XBMC is parsing for "bluray", "dvd", etc.? If it is that's news to me ... I'm not saying it's not, I just had no clue it does if that's correct. Can anyone confirm that for a fact? Is it looking for one of those words in the filename to display the correct codec information in the skin?

I think we also need to differentiate between offline media support and DVD cataloging support. They are sort of similar but not exactly the same. I would like to implement DVD cataloging support, or in other words the ability to add movies you have on DVD (and Bluray, etc.) to the library in XBMC and when selected XBMC asks you to "Please Insert Disc" with a Play and Cancel buttom attached (and maybe Eject button would be handy too Smile ). Offline media support is more about cataloging individual files on media that can be removed, that's more like having multiple movies on a USB drive, etc. That's not what I'm after. I actually think there's been a few attempts at such a feature and none have made it into the SVN so far for various reasons. I would like to keep things simple with just DVD catalog support. Maybe in the future that can be expanded for offline support, etc., but who knows.

Hope that clarifies things.

Thanks,
Harry


- jmarshall - 2010-09-27

The skin is looking for that, not XBMC per-se.

XBMC may look for it in the future though.


- Harry Muscle - 2010-09-27

jmarshall Wrote:The skin is looking for that, not XBMC per-se.

XBMC may look for it in the future though.

Ahh, interesting. Btw, since you're one of the Team-XBMC devs, any input on my proposed solution for this. I've spoken with Spiff a little on IRC already, but more input is always better. Any preference on how DVD catalog support is implemented? Hoping to start on the patch tomorrow.

Thanks,
Harry


- da-anda - 2010-09-27

@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.

@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.

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"

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).


- Harry Muscle - 2010-09-28

jmarshall Wrote:The skin is looking for that, not XBMC per-se.

XBMC may look for it in the future though.

That's sort of part of the patch that I'm trying to create. You would happen to know where to look in the skin's code to disable this feature since I wanna create it in XBMC.

Thanks,
Harry


- spiff - 2010-09-28

with confluence you can simply disable the skin option for now.


- Harry Muscle - 2010-09-30

da-anda Wrote:@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.

Quote:@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.

Quote: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.

Quote: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 Smile

Thanks,
Harry


- Harry Muscle - 2010-09-30

Patch will be going up tomorrow on trac (too late tonight to do it). But just to summarize what it will accomplish is provide support for stub files. Stub files are files created to represent something else. In our case files that have certain extensions that represent the respective disc type. For example:

name.dvd will represent a DVD disc
name.blu will represent a BluRay disc
name.hdd will represent a HDDVD disc
name.vhs will represent a VHS tape ... yup, that's right Smile ... the confluence skin actually has support for this media flag and the code to recognize the codec is all there, so I figured why not add it ... in case anyone actually still has these Eek

All file extensions are tweakable thru advancedsettings.xml so you can change them, add more, remove these, etc.

When scanned into the database the stream details (ie: media flags) will be set according to what type of media the stub file represents. When the user selects an entry from the library that's linked to a stub file, XBMC will present you with the appropriate prompt. Ranging from "can't play this" for VHS, to "please insert DVD and press play button".

Thanks,
Harry


- Harry Muscle - 2010-09-30

Once the patch is accepted into the SVN, I'm hoping to add disc number support too. I'm thinking the idea of adding the disc number to the file name might get too cumbersome, since like da-anda mentioned we might run into issues with stacking, etc. So I was thinking what if the numbers are stored inside the stub file. Sort of a simplified nfo file idea. So a stub file representing DVD #12 would have this content:

Code:
<number>12</number>

and it would be called (for example):

Code:
Finding Nemo (2003).dvd

So when you select the library item linked to this stub file the prompt would ask you to insert dvd number 12.

If you don't need disc number support then your stub file would have nothing in it and the prompt would simply ask you to insert the dvd.

What does everyone think of this idea?

Thanks,
Harry


- pecinko - 2010-09-30

Harry Muscle Wrote:name.dvd will represent a DVD disc
name.blu will represent a BluRay disc
name.hdd will represent a HDDVD disc
Harry

Little inconvenience is that you'll have one naming scheme for "online" and different one for "offline" media.


- pecinko - 2010-09-30

Harry Muscle Wrote:
Code:
<number>12</number>
Harry

Aren't you breaking file=0 check this way? The other thing - this should probably go to nfo file for consistency, and you'll have to provide nfo support in either way.

But maybe I'm all astray.


- Harry Muscle - 2010-09-30

pecinko Wrote:Little inconvenience is that you'll have one naming scheme for "online" and different one for "offline" media.

Not exactly. This isn't offline support (ie: library items linked to files that are unavailable), it's stub file support (ie: library items linked to files that represent something). Stub file are special files that XBMC has to recognize as such and know what they are supposed to represent. Best way for that is to have a different extension. Just like XBMC knows to handle an .mkv file differently from an .avi file, it also needs to know that a .dvd file has to be handled differently.

If/when actual offline media support get's added, the naming of files will be identical to what you name them now (ie: .mkv, .avi, etc.). XBMC will just have to have a way of knowing that when those files can't be found, don't remove them from the library but instead ask for them.

Hope that clarifies things a little.

Thanks,
Harry