Additional naming convention for TV shows ripped from DVDs

[wazza]

With support for VIDEO_TS files it would be nice to handle ripped TV series.

A TV series box set ripped to a hard drive could look like:

~/Movies/Battlestar Gallactica/Season 1/Disc 1/
                                        Disc 2/
                                        Disc 3/
                                        Disc 4/
                               Season 2/Disc 1/
                                        Disc 2/
                                        Disc 3/
                                        Disc 4/

with a VIDEO_TS directory in each "Disc X" folder.

The current naming convention for VIDEO_TS scenarios is the parent directory is used as the film name, but this won't work for ripped TV shows because it tries to resolve "Disc X" as the title.

It would be nice to support

~/Movie/<name>/<Season>/<Disc> or
~/Movie/<name>/<Disc> (for single season)

as a naming convention.

[gbooker]

That's very difficult. There is not consistent number of episodes per disc across shows.

Patches welcome.

[wazza]

I'm happy to help with a patch, please bear with my as I get started.

I have registered with the site, so any tips on how you like to receive patches etc can be sent to my email address.

[gbooker]

Patches are best put in tickets. For example, a patch for this is best attached to this ticket.

A patch for something which doesn't already have a ticket about it is best put in a newly created ticket.

[wazza]

Ok, I'll see what I can come up with. Between learning Objective-C and familiarising myself with the Sapphire code I can't promise anything for at least a couple of weeks, but I'll give it a go.

If I have questions about the code is this the best place to ask, or is there a wiki link/email address I should use?

[gbooker]

We understand that it takes time to learn a new language, and we wouldn't get to something like this until long after you could complete it.

The developers tend to talk via IM with each other; but we are also often lurking in the  #awkward channel

Sapphire should be fairly well documented; at least as far as its functions go. If you run doxygen on the doxyfile in the source, you will get some nice HTML documentation on classes and public functions.

[wazza]

Well it turned out that most of the work had already been done for me. The existing naming conventions work for directories also. This solves to difficulty of different discs containing different numbers of episodes, the user is in charge of this as (s)he follows the naming convention.

If my directory follows the same naming convention as for a file

e.g. ~/Movies/BSG/Battlestar.Galactica.S01E01-E04/VIDEO_TS

Then Sapphire will accept this.

The attached diff file is a small set of mods, as well as updated text for the supported file types page

Changeset:

M      SapphireFrappliance/SapphireMetaData.h
M      SapphireFrappliance/SapphireMetaData.m
M      SapphireFrappliance/SapphireTVShowImporter.m

Notes:
Added function totalFileSize to recursively check a VIDEO_TS directory and calculate the total size, not just directory size (~102 Bytes)
Method size for metadata changed from long long to unsigned long long (DVDs over 6GB were turning into negative numbers and confusing things a bit)
Added function combine:withMultipleEpisodes. The original combine:with method was only combining information from the first and last episodes in a multi-episode file.

For multiple episodes the title keys were getting too long, so the description key is used to list the episodes. The title key is changed to "Episode X - Y"

Issues:

One problem I've spent a few wasted nights on was trying lay out the episode titles nicely in the summary. I tried spreading them out with newline characters, but the summary box forces strange justification like this

------------------ Summary Width ----------------
s   p   a   c   e   d        t   i   t    l   e
                                  Justified title
                                  Justified title
                                  Justified title
final title
-------------------------------------------------

I think formatting of the summary box is hidden in BackRow, so I don't know if there's a way to change it.

[gbooker]

I'd like to look at this patch, but the ripped-tv-shows.diff file is really a .tar.gz file, containing another copy of supported_file_types.txt. Could you re-upload the patch?

[anonymous]

I don't know what happened there, sorry about that.

I've uploaded the diff separately.

I've noticed with my changes that file sizes are fluctuating between their proper formats (e.g. 6.6GB) and wildly strange numbers (1717989.....0GB) would storing the size as a string be a good idea, or would that break other parts?

[gbooker]

Long longs are 64-bit in size. There is no need to use unsigned, because the signed can express values up to 2^{63. That's about 10}19. No file is anywhere near that big.

We changed from longs to long longs a while ago, because longs loop to negative numbers at 2G, and I already had a few files that were 2+G in size.

Storing as a string will break future development techniques. We are currently redesigning the backend metadata to be much more powerful. Actually, I just redid it to handle this situation much more gracefully. I'll discuss it more once it is decent enough to commit into the repository.

[wazza]

I'm having no problems with summarised sizes during the original import. But if I close and re-open Sapphire the size of each ripped DVD changes.

In the Property List Editor the size shows up as a negative integer, which I think is causing the problems I see once I return to Sapphire. Is is possible that the plist format currently only supports longs which is why I'm seeing sizes as negatives? All ripped DVDs are over 2G.

[gbooker]

There is something very important to note: A negative bug in Property List Editor does not mean that the actual value is negative Property List Editor is buggy, as in it cannot handle long long values. Try this code and see what happens:

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

	long long size = 2300 * 1024;
	size *= 1024;
	
	NSNumber *num = [NSNumber numberWithLongLong:size];
	size *= 4;
	NSNumber *biggerNum = [NSNumber numberWithLongLong:size];
	NSDictionary *dict = [NSDictionary dictionaryWithObjectsAndKeys:
						  num, @"Number",
						  biggerNum, @"Big Num",
						  nil];
	
	[dict writeToFile:@"test.plist" atomically:YES];
	
	NSDictionary *dict2 = [NSDictionary dictionaryWithContentsOfFile:@"test.plist"];
	NSNumber *num2 = [dict2 objectForKey:@"Number"];
	
	long long size2 = [num2 longLongValue];
	NSNumber *bigNum2 = [dict2 objectForKey:@"Big Num"];
	size2 = [bigNum2 longLongValue];
	
    [pool drain];
    return 0;
}

You can see quite clearly that Property List Editor is buggy in this situation. So, the real question is what is the value in the real plist?

[wazza]

Sorry for the late response, lots of things on the go at the moment.

You are right in saying the property editor is buggy, it cannot handle long longs (signed or unsigned). If I modify the settings in the editor and re-save , it saves the sizes as (possibly negatively converted) integers. Hence why I'm seeing the strange behaviour, it was after I modified and saved in the editor.

It's clearly not Sapphires fault this is happening, but if users are fiddling with the metadata.plist file then this will crop up occasionally.

If numbers are modified then the first 4 bytes will be FFFF FFFF, one work around would be to mask the size with 0000 0001 1111 1111, which would result in the original value. (Or at least it would for values less than 0000 0002 0000 0000, but a ripped DVD will never be this size, until people start ripping Blu-ray at least :-) )

[gbooker]

Or.... just wait for Apple to fix it. This bug has existed for years, and interestingly enough, shortly after I posted code which demonstrates it, Apple fixes the bug in the next iPhone SDK.