Opened 9 years ago

Last modified 9 years ago

#145 new Enhancement

Additional naming convention for TV shows ripped from DVDs

Reported by: wazza Owned by:
Priority: normal Milestone:
Component: Other Version: 1.0b5
Keywords: Cc:


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.

Attachments (2)

ripped_tv_shows.tar.gz (1.8 KB) - added by wazza 9 years ago.
ripped-tv-shows.diff (5.3 KB) - added by anonymous 9 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 9 years ago by gbooker

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

Patches welcome.

comment:2 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by 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?

comment:5 Changed 9 years ago by 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.

Changed 9 years ago by wazza

comment:6 Changed 9 years ago by 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


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

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"


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.

comment:7 Changed 9 years ago by 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?

Changed 9 years ago by anonymous

comment:8 Changed 9 years ago by 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?

comment:9 Changed 9 years ago by gbooker

Long longs are 64-bit in size. There is no need to use unsigned, because the signed can express values up to 263. That's about 1019. 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.

comment:10 Changed 9 years ago by 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.

comment:11 Changed 9 years ago by 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",
	[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?

comment:12 Changed 9 years ago by 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 :-) )

comment:13 Changed 9 years ago by 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.

Note: See TracTickets for help on using tickets.