[m.savazzi]

Here's two code changes that helped me wrangle a TV Show directory hierarchy into shape for .NFO purposes for XBMC using Ember.

(This was from the 1.3.1.13 branch from Github.)

First: in SelectEpisodeRow() in frmMain fill in the episode information from the info that we do have
if calling LoadEpisodeInfo is inappropriate.

Can you explain better why you added that?

Second: In ScanTVSourceDir() search ALL subdirectories of the root of a TV show and not JUST the immediate sub-directories.

I'd imagine these ought to work against 1.4.x if they make sense.

Thoughts?
Bill

This can make the search even longer, can you explain which structure you have?

[rassilon22]

Here's two code changes that helped me wrangle a TV Show directory hierarchy into shape for .NFO purposes for XBMC using Ember.

(This was from the 1.3.1.13 branch from Github.)

First: in SelectEpisodeRow() in frmMain fill in the episode information from the info that we do have
if calling LoadEpisodeInfo is inappropriate.

Can you explain better why you added that?

Sure, if the detected media file doesn't match any of the normal file naming regular expression patterns to be automatically scraped the path name to the media file doesn't show up in the episode info portion of the UI.
Knowing the full path lets me manually correct the Season and Episode # of the file in question. Rescraping the show will correctly generate the NFO for XBMC.

Second: In ScanTVSourceDir() search ALL subdirectories of the root of a TV show and not JUST the immediate sub-directories.

I'd imagine these ought to work against 1.4.x if they make sense.

Thoughts?
Bill

This can make the search even longer, can you explain which structure you have?

Sure:
* Doctor Who 1963
|
+-- s1e01 An Unearthly Child
| |
| +--- s01e01p1 An Unearthly Child.avi
| +---- s01e01p2 The Cave of Skulls.avi
| +----- etc...
....
+--- s26e159 Survival
| |
| +--- Dr Who - 158 - Survival - 1 of 3.avi
| +--- Dr Who - 158 - Survival - 2 of 3.avi
| +--- Dr Who - 158 - Survival - 3 of 3.avi

So basically, the directory structure doesn't match the normal expected structure and renaming all of these files would drive anyone insane.
Since literally every file uses story arc episode numbering and not the episode numbering that TVDB uses.

Thus, Ember to the rescue.

In terms of longer to scan it's actually not that bad because it's the exception rather than the rule of media directory structures.

Thanks,
Bill

[m.savazzi]

* Doctor Who 1963
|
+-- s1e01 An Unearthly Child
| |
| +--- s01e01p1 An Unearthly Child.avi
| +---- s01e01p2 The Cave of Skulls.avi
| +----- etc...
....
+--- s26e159 Survival
| |
| +--- Dr Who - 158 - Survival - 1 of 3.avi
| +--- Dr Who - 158 - Survival - 2 of 3.avi
| +--- Dr Who - 158 - Survival - 3 of 3.avi

So basically, the directory structure doesn't match the normal expected structure and renaming all of these files would drive anyone insane.

I renamed all of my files to have TMDB numbering

It's quite easy with TheAdvancedRenamer

[DanCooper]

I'm working on the simplified settings.
What do you think about this?

[m.savazzi]

I'm working on the simplified settings.
What do you think about this?

Nice,
but what you mean with Use on the first checkbox?

Is not clear


If you mean "Active" it should be a level above the others and the below ones should be disabled if a setting in not active.
If we want them to be exclusive (either Frodo, either YAMJ) they should be radio buttons

---

Anyway I found and fixed couple of bugs, sent them to GitHub

[DanCooper]

I want to use both Media Center at the same time.

The "Use" checkbox enable and disable the sub-checkboxes. I don't know if we really need this "Use"-checkboxes =)
But when we have this situation...

Code:

If Master.eSettings.FrodoUse Then
     If Master.eSettings.FrodoPoster
     If Master.eSettings.FrodoFanart
End If

If Master.eSettings.YAMJUse Then
     If Master.eSettings.YAMJPoster
     If Master.eSettings.YAMJFanart
End If

... we can skip a complete XBMC/YAMJ part. I think this make the code faster.

And i think it's nice for users to save the sub-settings (NFO, Poster...) and deactivate only the "Use"-checkbox to dissable the XBMC/YAMJ settings. Therefore, I do not want to disable the sub-options.

Atm, if you check the "Use"-option and you have no (prechecked) sub-options checked, all sub-options will be activated.

Code:

Private Sub chkFrodoUse_CheckedChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles chkFrodoUse.CheckedChanged
        Me.SetApplyButton(True)

        If Me.chkFrodoUse.Checked Then
            Me.chkFrodoBanner.Enabled = True
            Me.chkFrodoClearArt.Enabled = True
            Me.chkFrodoDiscArt.Enabled = True
            Me.chkFrodoExtrafanart.Enabled = True
            Me.chkFrodoExtrathumbs.Enabled = True
            Me.chkFrodoFanart.Enabled = True
            Me.chkFrodoLogo.Enabled = True
            Me.chkFrodoNFO.Enabled = True
            Me.chkFrodoPoster.Enabled = True
            Me.chkFrodoTrailer.Enabled = True
            If Not (Me.chkFrodoBanner.Checked OrElse Me.chkFrodoClearArt.Checked OrElse Me.chkFrodoDiscArt.Checked OrElse _
                    Me.chkFrodoExtrafanart.Checked OrElse Me.chkFrodoExtrathumbs.Checked OrElse Me.chkFrodoFanart.Checked OrElse _
                    Me.chkFrodoLogo.Checked OrElse Me.chkFrodoLogo.Checked OrElse Me.chkFrodoNFO.Checked OrElse _
                    Me.chkFrodoPoster.Checked OrElse Me.chkFrodoTrailer.Checked) Then
                Me.chkFrodoBanner.Checked = True
                Me.chkFrodoClearArt.Checked = True
                Me.chkFrodoDiscArt.Checked = True
                Me.chkFrodoExtrafanart.Checked = True
                Me.chkFrodoExtrathumbs.Checked = True
                Me.chkFrodoFanart.Checked = True
                Me.chkFrodoLogo.Checked = True
                Me.chkFrodoNFO.Checked = True
                Me.chkFrodoPoster.Checked = True
                Me.chkFrodoTrailer.Checked = True
            End If
        Else
            Me.chkFrodoBanner.Enabled = False
            Me.chkFrodoClearArt.Enabled = False
            Me.chkFrodoDiscArt.Enabled = False
            Me.chkFrodoExtrafanart.Enabled = False
            Me.chkFrodoExtrathumbs.Enabled = False
            Me.chkFrodoFanart.Enabled = False
            Me.chkFrodoLogo.Enabled = False
            Me.chkFrodoNFO.Enabled = False
            Me.chkFrodoPoster.Enabled = False
            Me.chkFrodoTrailer.Enabled = False

        End If
    End Sub

[bodrick]

So I had an idea for dealing with the differences in say XBMC and YAMJ, rather than having a lot of settings, my thought was to maybe instead utilize a xslt template type system. Since the data itself is already XML, doing an XSLT on it should be fairly simple depending on what output you want to use, further more this allows for easy updates and customization going forward. Of course this is still just an idea that I've not yet tested.

[m.savazzi]

So I had an idea for dealing with the differences in say XBMC and YAMJ, rather than having a lot of settings, my thought was to maybe instead utilize a xslt template type system. Since the data itself is already XML, doing an XSLT on it should be fairly simple depending on what output you want to use, further more this allows for easy updates and customization going forward. Of course this is still just an idea that I've not yet tested.

GREAT!!!!!!

I'm not good in XSLT transformations but if all the info is there it should be the best path forward

I would keep XBMC as the master NFO format and the apply the XSLT once the file is created if a YAMJ NFO is needed.

Super quick and clean!

[m.savazzi]

DanCooper,
question: which is the status of the new DB?

Once we decide to move we will have to change all queries like: SELECT * FROM TVShows ORDER BY Title COLLATE NOCASE
as the program is dependant on the field order and that WILL CHANGE for sure SIGH
(another bad habit! use the *)

The new DB is crucial for a lot of stuff like clearart etc...

Boderick,
were you able to give it a look?

[rassilon22]

I renamed all of my files to have TMDB numbering

It's quite easy with TheAdvancedRenamer

I couldn't find that tool, but using Ember to set the season/episode #s in the NFO made the process of actually renaming all of the files to make XBMC happy an absurdly simple one.

I tried to look at the listed rename tools on the XBMC wiki but the ones that contact TVDB or tvrage weren't flexible enough to get the job done reliably for all of the episodes. One that came particularly close, but the javascript custom rename action mechanism didn't let me create an ActiveX object to extract the data from the NFO file. (There were about ~720 episode files that needed renaming, if it was ~100 it wouldn't have been that bad, but I just wasn't going to rename that many episodes manually, ugh.)

Once Ember had generated the proper NFO files a simple Python program did the renaming for me.

The Python code simply finds all media files under the root path, parses the expected .NFO file and constructs an appropriate new base name based on the season/episode/title in the NFO file. It then renames the original base to the new one (i.e. Dr Who - blah blah* to S002E002_blah blah*). This includes the original media file, the NFO file, and any thumbnail files.

I needed to special case the title portion of the file name some to deal properly with Doctor Who reconstructed episode notation. Otherwise, I'd post the code for others.

After that ran successfully I then wrote another tiny program to take the "(reconstruction)" in the file name and migrated it into the .NFO <title> element so XBMC would show if the episode was reconstructed.

Trivia for the bored:
Some of Dr Who's original episodes were lost due to the BBC not archiving them properly and they were actually thrown away. The reconstructed episodes feature some video bits interspersed with either narration/episode audio and photos taking during the filming of the episode. Thus why it's interesting to know in XBMC if the episode is one of these reconstructed suckers.

Bill

[bodrick]

DanCooper,
question: which is the status of the new DB?

Once we decide to move we will have to change all queries like: SELECT * FROM TVShows ORDER BY Title COLLATE NOCASE
as the program is dependant on the field order and that WILL CHANGE for sure SIGH
(another bad habit! use the *)

The new DB is crucial for a lot of stuff like clearart etc...

Boderick,
were you able to give it a look?

Not yet, been busy with my real job the past little while, but I'm hoping I can get some time over the next couple of days to look it over.

---

So I had an idea for dealing with the differences in say XBMC and YAMJ, rather than having a lot of settings, my thought was to maybe instead utilize a xslt template type system. Since the data itself is already XML, doing an XSLT on it should be fairly simple depending on what output you want to use, further more this allows for easy updates and customization going forward. Of course this is still just an idea that I've not yet tested.

GREAT!!!!!!

I'm not good in XSLT transformations but if all the info is there it should be the best path forward

I would keep XBMC as the master NFO format and the apply the XSLT once the file is created if a YAMJ NFO is needed.

Super quick and clean!

That was my thought too, use the XBMC format, then do an XSLT transform on it for other formats. I've done a bit of XSLT type stuff over the years, a little rusty but should be fairly easy to pick it up again.

[rassilon22]

I would keep XBMC as the master NFO format and the apply the XSLT once the file is created if a YAMJ NFO is needed.

Super quick and clean!

That was my thought too, use the XBMC format, then do an XSLT transform on it for other formats. I've done a bit of XSLT type stuff over the years, a little rusty but should be fairly easy to pick it up again.

I'm afraid I don't have many movies or indeed even YAMJ lying around but if someone could post a gist (or whatever) of some sample XBMC/YAMJ equivalent files I could look into writing up the necessary XSLT.

Fortunately, the NFO files don't deal with namespaces and namespaces are particularly painful with the .Net XSLT engine. (Since it doesn't support XSLT 2.0. )

Additionally, Visual Studio does have a XSLT debugger which certainly helps the process.

Bill

[m.savazzi]

I would keep XBMC as the master NFO format and the apply the XSLT once the file is created if a YAMJ NFO is needed.

Super quick and clean!

That was my thought too, use the XBMC format, then do an XSLT transform on it for other formats. I've done a bit of XSLT type stuff over the years, a little rusty but should be fairly easy to pick it up again.

I'm afraid I don't have many movies or indeed even YAMJ lying around but if someone could post a gist (or whatever) of some sample XBMC/YAMJ equivalent files I could look into writing up the necessary XSLT.

Fortunately, the NFO files don't deal with namespaces and namespaces are particularly painful with the .Net XSLT engine. (Since it doesn't support XSLT 2.0. )

Additionally, Visual Studio does have a XSLT debugger which certainly helps the process.

Bill

Great, here are some XBMC NFO examples. http://sdrv.ms/10a22yr

Note that there is a NON standard XML file for multiple episode files.
The structure is WRONG as it does have multiple root elements

Code:

<episodedetails>
</episodedetails>

<episodedetails>
</episodedetails>

to bypass the issue with Ember, YAMJ and other tools we add a fakeroot element

Code:

<fakeroot>
  <episodedetails>
  </episodedetails>

  <episodedetails>
  </episodedetails>
</fakeroot>

I do not know how XSLT transformation works but is possible that we need to add the <fakeroot> element, transform and then remove it.

---

DanCooper,
question: which is the status of the new DB?

Once we decide to move we will have to change all queries like: SELECT * FROM TVShows ORDER BY Title COLLATE NOCASE
as the program is dependant on the field order and that WILL CHANGE for sure SIGH
(another bad habit! use the *)

The new DB is crucial for a lot of stuff like clearart etc...

Boderick,
were you able to give it a look?

Not yet, been busy with my real job the past little while, but I'm hoping I can get some time over the next couple of days to look it over.

---

So I had an idea for dealing with the differences in say XBMC and YAMJ, rather than having a lot of settings, my thought was to maybe instead utilize a xslt template type system. Since the data itself is already XML, doing an XSLT on it should be fairly simple depending on what output you want to use, further more this allows for easy updates and customization going forward. Of course this is still just an idea that I've not yet tested.

GREAT!!!!!!

I'm not good in XSLT transformations but if all the info is there it should be the best path forward

I would keep XBMC as the master NFO format and the apply the XSLT once the file is created if a YAMJ NFO is needed.

Super quick and clean!

That was my thought too, use the XBMC format, then do an XSLT transform on it for other formats. I've done a bit of XSLT type stuff over the years, a little rusty but should be fairly easy to pick it up again.

looking forward for your feedback!

[rassilon22]

That was my thought too, use the XBMC format, then do an XSLT transform on it for other formats. I've done a bit of XSLT type stuff over the years, a little rusty but should be fairly easy to pick it up again.

I'm afraid I don't have many movies or indeed even YAMJ lying around but if someone could post a gist (or whatever) of some sample XBMC/YAMJ equivalent files I could look into writing up the necessary XSLT.

Fortunately, the NFO files don't deal with namespaces and namespaces are particularly painful with the .Net XSLT engine. (Since it doesn't support XSLT 2.0. )

Additionally, Visual Studio does have a XSLT debugger which certainly helps the process.

Bill

Great, here are some XBMC NFO examples. http://sdrv.ms/10a22yr

Thanks. I looked at these, and at the Ember 1.4 NFO file code and the only difference I saw was:

Code:

    If AdvancedSettings.GetBooleanSetting("YAMJnfoFields", False) Then
            If Not String.IsNullOrEmpty(mMovie.FileSource) Then
            mMovie.Movie.VideoSource = mMovie.FileSource
        End If
        mMovie.Movie.IDMovieDB = "imdb"
    Else
        mMovie.Movie.IDMovieDB = String.Empty
        mMovie.Movie.VideoSource = String.Empty
    End If

This logic can't be encoded in a XSLT without having a XSLT for both XBMC and YAMJ from a common base XML serialization. i.e. superset XML -> XBMC or superset XML -> YAMJ.
Would this still be worth doing via XSLT? It doesn't seem like it to me at the moment.

The rest of the YAMJ logic I saw seemed more to do with movie set management logic differences and other fanart/poster related tweaks and not with the actual NFO content.

Did I miss something?

About those <episodedetail> multiple root elements: Yeah, those sure are lame. Ugh.
The multipart <episodedetail> regex in the TV Episode detail NFO loading logic looks suspect. Has anybody made sure that works recently? Remember, '*' and '?' by default are greedy in regular expressions. The regex looked like it would match from the first episodedetail element open tag to the last episodedetail element close tag.

Bill

[m.savazzi]

Thanks. I looked at these, and at the Ember 1.4 NFO file code and the only difference I saw was:

Code:

    If AdvancedSettings.GetBooleanSetting("YAMJnfoFields", False) Then
            If Not String.IsNullOrEmpty(mMovie.FileSource) Then
            mMovie.Movie.VideoSource = mMovie.FileSource
        End If
        mMovie.Movie.IDMovieDB = "imdb"
    Else
        mMovie.Movie.IDMovieDB = String.Empty
        mMovie.Movie.VideoSource = String.Empty
    End If

This logic can't be encoded in a XSLT without having a XSLT for both XBMC and YAMJ from a common base XML serialization. i.e. superset XML -> XBMC or superset XML -> YAMJ.
Would this still be worth doing via XSLT? It doesn't seem like it to me at the moment.

The rest of the YAMJ logic I saw seemed more to do with movie set management logic differences and other fanart/poster related tweaks and not with the actual NFO content.

Did I miss something?

I do not think is the only difference, is the only one implemented
someone using YAMJ should comment more on the NFO they would need for it to work fine.

We will have to check the image names, you're correct.

About those <episodedetail> multiple root elements: Yeah, those sure are lame. Ugh.
The multipart <episodedetail> regex in the TV Episode detail NFO loading logic looks suspect. Has anybody made sure that works recently? Remember, '*' and '?' by default are greedy in regular expressions. The regex looked like it would match from the first episodedetail element open tag to the last episodedetail element close tag.

Bill

I'm not good at RegEx, if you are you're super welcome to help
The original developer was using them a lot but we miss someone very good in them to see if they are still valid and/or to modify them.
In my experience the difficult part of regex is not to find the one that satisfies the direct case (I want to find top...) but to create one that excluded all the side cases (... but do not want topology).
In the movies / episode case is a mess, This is an episode foo S01E03 or foo x03 or foo x3 while this is NOT an episode Back to the future 3
etc....

M