[rassilon22]

This is driving me nuts.

Sometimes I get an error at runtime when the program tries to save the language_strings.log or the AdvancedSettings.xml file.

If anyone has an idea is more than welcome!

I just finished looking at the code paths for saving AdvancedSettings.xml. The file is persisted after EVERY small change to the data.
What COULD be going on is some other process watching the NTFS journal (or a directory change notification) and then opening the file behind our back.
(Like an Anti/Virus program.)

Look at all of those modules SaveSetup routines. They each make ~2-5 separate calls to the AdvacnedSettings class. The AdvancedSettings class saves the XML file for EACH of those methods. Ugh.

There are a couple of alternatives to this general dilemma:
* Refactor AdvancedSettings API contract so that it isn't nearly so Save happy.
This would be extra nice because the Save constructs the XML document from scratch each time it gets called.
* Alter the if File.Exists() then File.Delete() logic to catching an IOException if the Delete() fails, Thread.Sleep() (say 50ms or so) and try again 2-3 more times.
If you still fail after that then just re-throw the exception.

I haven't looked at the language_string case yet.

Bill

[rassilon22]

This is driving me nuts.

Sometimes I get an error at runtime when the program tries to save the language_strings.log or the AdvancedSettings.xml file.

If anyone has an idea is more than welcome!

I haven't looked at the language_string case yet.

Since everything in Ember deals with loading string resources I'm going to stab in the dark that it's a thread safety issue.

(Find All References of Get String on CodeMap made VS 2012 go into la la land. )

Try this:
Add these two fields at the end of the field region in clsLocalization.vb:

Code:

#If DEBUG Then
    Private Shared _loggingString As New Object
    Private Shared _loggingHelp As New Object
#End If

Then modify GetString and GetHelpString in the following manner:

GetHelpString:

Code:

SyncLock _loggingHelp
        Using fs1 As FileStream = New FileStream(_LogFile, FileMode.Append, FileAccess.Write)
            Using s1 As StreamWriter = New StreamWriter(fs1)
                s1.Write(String.Concat(ctrlName, vbTab, aStr, vbNewLine))
                s1.Flush()
                s1.Close()
            End Using
        End Using
End SyncLock

and:

GetString:

Code:

SyncLock _loggingString
        Using fs1 As FileStream = New FileStream(_LogFile, FileMode.Append, FileAccess.Write)
            Using s1 As StreamWriter = New StreamWriter(fs1)
                s1.Write(String.Concat(Assembly, vbTab, ID, vbTab, tStr, vbNewLine))
                s1.Flush()
                s1.Close()
            End Using
        End Using
End SyncLock

If an exception still occurs then my suggestion would be to either:
* Delay/Retry under the assumption you have some kind of A/V like sw causing you grief.
or
* Ignore writing this string to the string log since someone else is preventing our appending write.

I'll be trying this out locally but thought I'd share.

Hope this helps,
Bill

[m.savazzi]

Oh. Yeah, just fixing the XmlViewer is the easier thing to do I would imagine. I'll try to look into it a little later this week as I've only once looked at the RTF spec once ages ago. Ideally the namespace prefixes would be a slightly different color.

Ah here's what I was looking for the URL that XmlViewer came from: MS XmlViewer Download

That URL contains a link to a version of the RTF spec.

Oh ick. XmlViewer is only a one time highlighting.
Maybe we need to look into ICSharpCode.TextEditor. Its a LGPL subset of SharpDevelop that does text editor goo and syntax highlighting.
That ought to get us incremental highlighting as well. (plus hopefully no RTF )

Edit:
Hrm. Just noticed that they no longer use the WinForms based text editor but here's the requisite github.com link to the 3.x branch of SharpDevelop.

Bill

I edited the code to remove the XLMNS string as is not essential...

I'm trying to see if I can incorporate one of those libraries.

M

---

This is driving me nuts.

Sometimes I get an error at runtime when the program tries to save the language_strings.log or the AdvancedSettings.xml file.

If anyone has an idea is more than welcome!

I just finished looking at the code paths for saving AdvancedSettings.xml. The file is persisted after EVERY small change to the data.
What COULD be going on is some other process watching the NTFS journal (or a directory change notification) and then opening the file behind our back.
(Like an Anti/Virus program.)

Look at all of those modules SaveSetup routines. They each make ~2-5 separate calls to the AdvacnedSettings class. The AdvancedSettings class saves the XML file for EACH of those methods. Ugh.

There are a couple of alternatives to this general dilemma:
* Refactor AdvancedSettings API contract so that it isn't nearly so Save happy.
This would be extra nice because the Save constructs the XML document from scratch each time it gets called.
* Alter the if File.Exists() then File.Delete() logic to catching an IOException if the Delete() fails, Thread.Sleep() (say 50ms or so) and try again 2-3 more times.
If you still fail after that then just re-throw the exception.

I haven't looked at the language_string case yet.

Bill

The idea of the save on every change to be sure to have all settings recoded correctly... now if we remove the save on every change we have to check all to code to save after each major mod.

[m.savazzi]

This is driving me nuts.

Sometimes I get an error at runtime when the program tries to save the language_strings.log or the AdvancedSettings.xml file.

If anyone has an idea is more than welcome!

I haven't looked at the language_string case yet.

Since everything in Ember deals with loading string resources I'm going to stab in the dark that it's a thread safety issue.

(Find All References of Get String on CodeMap made VS 2012 go into la la land. )

Try this:
Add these two fields at the end of the field region in clsLocalization.vb:

Code:

#If DEBUG Then
    Private Shared _loggingString As New Object
    Private Shared _loggingHelp As New Object
#End If

Then modify GetString and GetHelpString in the following manner:

GetHelpString:

Code:

SyncLock _loggingHelp
        Using fs1 As FileStream = New FileStream(_LogFile, FileMode.Append, FileAccess.Write)
            Using s1 As StreamWriter = New StreamWriter(fs1)
                s1.Write(String.Concat(ctrlName, vbTab, aStr, vbNewLine))
                s1.Flush()
                s1.Close()
            End Using
        End Using
End SyncLock

and:

GetString:

Code:

SyncLock _loggingString
        Using fs1 As FileStream = New FileStream(_LogFile, FileMode.Append, FileAccess.Write)
            Using s1 As StreamWriter = New StreamWriter(fs1)
                s1.Write(String.Concat(Assembly, vbTab, ID, vbTab, tStr, vbNewLine))
                s1.Flush()
                s1.Close()
            End Using
        End Using
End SyncLock

If an exception still occurs then my suggestion would be to either:
* Delay/Retry under the assumption you have some kind of A/V like sw causing you grief.
or
* Ignore writing this string to the string log since someone else is preventing our appending write.

I'll be trying this out locally but thought I'd share.

Hope this helps,
Bill

I'll try it...

[rassilon22]

Is there any particular reason the scaper modules (in the 1.4 source) don't have API keys (for like fanart.tv) or whatever?
I would have thought API keys would be primarily about the apps and not the individual end users.

Thanks,
Bill

[m.savazzi]

Yes,
it's against the policy of all sites. The API keys are personal or (in case of closed source projects) are associated to the developer and app.
In an open source project it would lead to have someone (me, you or who requires the ApI key) to be legally responsible for its use (and abuse) by everyone in the universe.
This is not good!

So I removed all api keys and add the property, as well as the link to get them

[rassilon22]

Ah. Thanks for the explanation.

I just submitted a pull request for improved IMDB poster scraping of ._V1_SX214_CR0,0,214,317_.jpg and ._V1_SY295_SX197_.jpg suffixes.

Fyi,
Bill

[rassilon22]

I just added a pull request for tweaking the AdvancedSettings class to have the read methods to continue use the 'Shared' functions.
However, the write methods now require the callers to create an instance of the AdvancedSettings class inside a using block.
The Dispose method of the instance executes the save of the .xml file.

Hopefully, this will help prevent the errors folks were seeing.

Comments welcome on this one. I haven't been super complete in testing all of the callers because I don't have API keys for all of the scrapers yet.

Thoughts?

Thanks,
Bill

[Cocotus]

I just added a pull request for tweaking the AdvancedSettings class to have the read methods to continue use the 'Shared' functions.
However, the write methods now require the callers to create an instance of the AdvancedSettings class inside a using block.
The Dispose method of the instance executes the save of the .xml file.

Hopefully, this will help prevent the errors folks were seeing.

Comments welcome on this one. I haven't been super complete in testing all of the callers because I don't have API keys for all of the scrapers yet.

Thoughts?

Thanks,
Bill

Sounds good to me! Any improvement of reading the xml settings is welcomed! I get Advanced.xml errors nearly every Ember session so it's great. Btw, I finished the trakt.tv scraper (for now only download info from trakt.tv, no trakt.tv submit) and will test it now

[pepar]

subscribed. apparently, all of the YAMJ chatter is in this thread ...

[rassilon22]

Couple of questions for everybody:
Is the new schema you folks discussed been checked into the 1.4 tree yet?
If not, does the new schema have better support for the weirdness of TV episodes? (Specifically, multi-episode media files)

I ask because I suspect that making it better support the TV episode weirdness would be required to flush out a TV show renamer that was less likely to produce almost but slightly incorrect output in such cases.

m.savazzi: Were you going to look into that WinForm text editor thing for the manual edits? If not I might give it a shot.

Thanks,
Bill

[m.savazzi]

Couple of questions for everybody:
Is the new schema you folks discussed been checked into the 1.4 tree yet?

No is not. If you want I can share it with you.

If not, does the new schema have better support for the weirdness of TV episodes? (Specifically, multi-episode media files)

One of the major changes in the structure is to decouple the "metadata" information (episode, show, fanart, etc) from the "effective file" this should allow a much higher degree of freedom and allow to address new image types like clearart as well as other file formats like multipart episodes.

Just to be clear MULTIEPISODE files should work perfectly
They are like foo S01E01E02E03.avi
In EMM you should find the THREE episodes and ONE .NFO file named S01E01E02E03.NFO with a NON valid XML file (I opened several bugs for this to XBMC) with the three <episodedetails/> roots

Instead Multipart episodes are not supported (and I do not know how XBMC handles them):
foo S01E01 part 1.avi
foo S01E01 part 2.avi

I ask because I suspect that making it better support the TV episode weirdness would be required to flush out a TV show renamer that was less likely to produce almost but slightly incorrect output in such cases.

Can explain better?

m.savazzi: Were you going to look into that WinForm text editor thing for the manual edits? If not I might give it a shot.
Thanks,
Bill

I think I already fixed it (I simply removed the XMLNS as they are not effectively needed )

[rassilon22]

One of the major changes in the structure is to decouple the "metadata" information (episode, show, fanart, etc) from the "effective file" this should allow a much higher degree of freedom and allow to address new image types like clearart as well as other file formats like multipart episodes.

Just to be clear MULTIEPISODE files should work perfectly
They are like foo S01E01E02E03.avi
In EMM you should find the THREE episodes and ONE .NFO file named S01E01E02E03.NFO with a NON valid XML file (I opened several bugs for this to XBMC) with the three <episodedetails/> roots

Instead Multipart episodes are not supported (and I do not know how XBMC handles them):
foo S01E01 part 1.avi
foo S01E01 part 2.avi

I ask because I suspect that making it better support the TV episode weirdness would be required to flush out a TV show renamer that was less likely to produce almost but slightly incorrect output in such cases.

Can explain better?

Sure, if the file is already named correctly for either multi-episode or multi-part reasons for XBMC if EMM doesn't understand all of those distinctions the odds are high that a bulk renamer might suggest an incorrect rename of the file.

Multi-part TV Episode naming is described in 2.3 of XBMC TV Show Naming.

XML manual editing: Yeah, I saw you removed the namespace change. I was just wondering if it was worth looking into a more complete solution. (Not so much because its needed per-say, but more because it's there. like those mountains for rock climbers. )

A copy of the new db schema would be cool.

Thanks,
Bill

[m.savazzi]

Sure, if the file is already named correctly for either multi-episode or multi-part reasons for XBMC if EMM doesn't understand all of those distinctions the odds are high that a bulk renamer might suggest an incorrect rename of the file.

Multi-part TV Episode naming is described in 2.3 of XBMC TV Show Naming.

Ok,
this sounds like something we have to fix. I'm not sure the RegEx now matches with XBMC ones.

I will add a task in the first post of the feature requests.

M

[Dragen]

Multiepisode filenames are handled very buggy in Ember.