• 1
  • 3
  • 4
  • 5(current)
  • 6
  • 7
  • 24
WIP Developer Area
#61
Ignore my comment about the regex thingy. It works just fine as is. (Aside from not using a global string constant for the regex that is used in multiple places.

I did notice that 1.4's Bulk Renamer dialog is broken atm. The underlying cause is that Ember generated .NFO files has loads of leading and trailing whitespace for the audio/video fields like aspectratio, etc...

My thought at the moment was to just always Trim in clsAPINFO.vb:GetBestVideo and GetBestAudio as well as clsAPINumUtils.cs:ConvertToSingle.

Sound good or should I do something else before submitting a pull request for it?

Thanks,
Bill
#62
(2013-06-24, 05:06)rassilon22 Wrote: Ignore my comment about the regex thingy. It works just fine as is. (Aside from not using a global string constant for the regex that is used in multiple places.

I did notice that 1.4's Bulk Renamer dialog is broken atm. The underlying cause is that Ember generated .NFO files has loads of leading and trailing whitespace for the audio/video fields like aspectratio, etc...

My thought at the moment was to just always Trim in clsAPINFO.vb:GetBestVideo and GetBestAudio as well as clsAPINumUtils.cs:ConvertToSingle.

Sound good or should I do something else before submitting a pull request for it?

Thanks,
Bill

I think is better to understand why the NFO is saved with those spaces.... sounds like a bug in the generation/save of the NFO.
I would fix it there not in the load part as the spaces could generate other errors... can you investigate it?
If you think I'm useful please use the +/- button to raise my reputation
#63
(2013-06-25, 15:25)m.savazzi Wrote:
(2013-06-24, 05:06)rassilon22 Wrote: I did notice that 1.4's Bulk Renamer dialog is broken atm. The underlying cause is that Ember generated .NFO files has loads of leading and trailing whitespace for the audio/video fields like aspectratio, etc...

My thought at the moment was to just always Trim in clsAPINFO.vb:GetBestVideo and GetBestAudio as well as clsAPINumUtils.cs:ConvertToSingle.

I think is better to understand why the NFO is saved with those spaces.... sounds like a bug in the generation/save of the NFO.
I would fix it there not in the load part as the spaces could generate other errors... can you investigate it?

I can look into the underlying cause as well, but NFO files aren't JUST generated by Ember after all. Smile

I wasn't too thrilled with the idea of tweaking the NFO XML serialization class in terms of modifying the data so that it would get modified when/if it gets saved out again.
I suppose all of the properties could trim the appropriate data before returning the content from the XML.

Bill
#64
(2013-06-24, 05:06)rassilon22 Wrote: Ignore my comment about the regex thingy. It works just fine as is. (Aside from not using a global string constant for the regex that is used in multiple places.

rassilon22,
can you please tell me which regEx is used in multiple places and is not global? that's wrong

M
If you think I'm useful please use the +/- button to raise my reputation
#65
(2013-06-25, 23:57)m.savazzi Wrote: rassilon22,
can you please tell me which regEx is used in multiple places and is not global? that's wrong

M

It's the multi-part episodedetails one in IsConformingEpNfo and LoadTVEpFromNFO.

Bill
#66
(2013-06-25, 16:15)rassilon22 Wrote: I can look into the underlying cause as well, but NFO files aren't JUST generated by Ember after all. Smile

Ok, I remember what the problem was it was the 1.4 manual .NFO file editing. (the colorized xml RTF control)
The 'xmlns:xsi="http://...."' bits get spit into the editor incorrectly as just the "http://..." which causes an infinite loop of exceptions due to an unexpected InvalidOperationException from trying to parse the (now invalid) text in the RTF control.

Breaking out of the infinite loop in the debugger and saving the result was what was giving me aspect ratios, etc that needed calling Trim() on. (Due to the nice indenting that's done when the XML is formatted into RTF.)

Want me to look into this some more? It shouldn't be that hard to spit out those namespace attributes correctly.
The existing check for namespace utilization is on the element itself. i.e. if you had something like this: <localNS:movie> where localNS was a local namespace pointing at a mythical .NFO XML schema.

Bill
#67
(2013-06-26, 04:18)rassilon22 Wrote:
(2013-06-25, 16:15)rassilon22 Wrote: I can look into the underlying cause as well, but NFO files aren't JUST generated by Ember after all. Smile

Ok, I remember what the problem was it was the 1.4 manual .NFO file editing. (the colorized xml RTF control)
The 'xmlns:xsi="http://...."' bits get spit into the editor incorrectly as just the "http://..." which causes an infinite loop of exceptions due to an unexpected InvalidOperationException from trying to parse the (now invalid) text in the RTF control.

Wow, I added that and with my NFOs was working correctly, can you send me an NFO that generates the issue?
then we can see how to fixe it.

(2013-06-26, 04:18)rassilon22 Wrote: Breaking out of the infinite loop in the debugger and saving the result was what was giving me aspect ratios, etc that needed calling Trim() on. (Due to the nice indenting that's done when the XML is formatted into RTF.)

Want me to look into this some more? It shouldn't be that hard to spit out those namespace attributes correctly.
The existing check for namespace utilization is on the element itself. i.e. if you had something like this: <localNS:movie> where localNS was a local namespace pointing at a mythical .NFO XML schema.

Bill

This is more reasonable as the file is messed up...
If you think I'm useful please use the +/- button to raise my reputation
#68
(2013-06-26, 14:43)m.savazzi Wrote:
(2013-06-26, 04:18)rassilon22 Wrote:
(2013-06-25, 16:15)rassilon22 Wrote: I can look into the underlying cause as well, but NFO files aren't JUST generated by Ember after all. Smile

Ok, I remember what the problem was it was the 1.4 manual .NFO file editing. (the colorized xml RTF control)
The 'xmlns:xsi="http://...."' bits get spit into the editor incorrectly as just the "http://..." which causes an infinite loop of exceptions due to an unexpected InvalidOperationException from trying to parse the (now invalid) text in the RTF control.

Wow, I added that and with my NFOs was working correctly, can you send me an NFO that generates the issue?
then we can see how to fixe it.

No need to do that. The Alien (1979).NFO file that you pointed me to as xbmc movie examples contains the problematic lines:

Code:
<?xml version="1.0" encoding="utf-8"?>
<movie xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <id TMDB="348">tt078748</id>
  <title>Alien</title>
...

The XML namespace declarations on the movie element are the problem bits for the manual editing code.

Bill
#69
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.

I thought there was a problem with the sequence of write and one keeping the file open. So I added a library to check the processes that are locking the file...
... and there is NO process locking the file.

this is the error:
The process cannot access the file '...\Ember-MM-Newscraper\EmberMM-Dev\Log\language_strings.log' because it is being used by another process.

here is the code I added:
http://mdetras.com/2011/06/11/get-proces...in-vb-net/

Code:
Dim _LogFile = Path.Combine(_sPath, "language_strings.log")
            Dim filePaths As New List(Of String)
            filePaths.Add(_LogFile)
            Dim Processes As IList(Of Process)
            Processes = clsFileLock.GetProcessesUsingFiles(filePaths)

just before
Code:
Using fs1 As FileStream = New FileStream(_LogFile, FileMode.Append, FileAccess.Write)


So that when the exception is thrown I can look at the Processes list to see if there is any, it's always empty!

If anyone has an idea is more than welcome!
If you think I'm useful please use the +/- button to raise my reputation
#70
(2013-06-26, 16:29)rassilon22 Wrote:
(2013-06-26, 14:43)m.savazzi Wrote:
(2013-06-26, 04:18)rassilon22 Wrote: Ok, I remember what the problem was it was the 1.4 manual .NFO file editing. (the colorized xml RTF control)
The 'xmlns:xsi="http://...."' bits get spit into the editor incorrectly as just the "http://..." which causes an infinite loop of exceptions due to an unexpected InvalidOperationException from trying to parse the (now invalid) text in the RTF control.

Wow, I added that and with my NFOs was working correctly, can you send me an NFO that generates the issue?
then we can see how to fixe it.

No need to do that. The Alien (1979).NFO file that you pointed me to as xbmc movie examples contains the problematic lines:

Code:
<?xml version="1.0" encoding="utf-8"?>
<movie xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <id TMDB="348">tt078748</id>
  <title>Alien</title>
...

The XML namespace declarations on the movie element are the problem bits for the manual editing code.

Bill

Investigating it... something strange happen in the tmp file:

<?xml version="1.0" encoding="utf-8"?>
<movie http://www.w3.org/2000/xmlns/xsi="http://www.w3.org/2001/XMLSchema-instance" http://www.w3.org/2000/xmlns/xsd="http://www.w3.org/2001/XMLSchema" >

The first line is screwed up...
If you think I'm useful please use the +/- button to raise my reputation
#71
(2013-06-26, 18:57)m.savazzi Wrote: Investigating it... something strange happen in the tmp file:

<?xml version="1.0" encoding="utf-8"?>
<movie http://www.w3.org/2000/xmlns/xsi="http://www.w3.org/2001/XMLSchema-instance" http://www.w3.org/2000/xmlns/xsd="http://www.w3.org/2001/XMLSchema" >

The first line is screwed up...

Yes, this is done by the colorizing process in XmlViewer's ProcessElement (IIRC). It's using attribute.Name in a String.Format() but is a XName where the ToString() method returns the namespace URL + the actual attribute name.
We just need to alter the Format() and then figure which properties on the XName to use here.


(2013-06-26, 18:41)m.savazzi Wrote: 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.

I thought there was a problem with the sequence of write and one keeping the file open. So I added a library to check the processes that are locking the file...
... and there is NO process locking the file.

this is the error:
The process cannot access the file '...\Ember-MM-Newscraper\EmberMM-Dev\Log\language_strings.log' because it is being used by another process.

here is the code I added:
http://mdetras.com/2011/06/11/get-proces...in-vb-net/

I've seen this happen with language_strings.log as well. I haven't bothered looking at it just yet.
You mentioned you added a library. Why would you do that when you can use SysInternals Process Explorer to see all of files/dlls/etc... that all processes use.

Specifically: http://technet.microsoft.com/en-us/sysin...s/bb896653

Bill
#72
Chaging library!

using ColorCode.... the one used on codeplex... and available from nuget

But it outputs HTML not RTF Sad

Sigh! no solution right now
If you think I'm useful please use the +/- button to raise my reputation
#73
Guys somehting is wrong with VIDEO_TS handling I think - for me Nfos are saved inside the VIDEO_TS folder of my DVD Images. - I want it to be in parent folder like
i.e.content of movie directory "Blade": fanart.jpg, movie.tbn, movie.nfo and "VIDEO_TS" folder

I think I have to check this
#74
(2013-06-26, 19:21)m.savazzi Wrote: Chaging library!

using ColorCode.... the one used on codeplex... and available from nuget

But it outputs HTML not RTF Sad

Sigh! no solution right now

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

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.

Bill
#75
(2013-06-26, 21:57)rassilon22 Wrote: 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. Smile

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

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
  • 1
  • 3
  • 4
  • 5(current)
  • 6
  • 7
  • 24

Logout Mark Read Team Forum Stats Members Help
Developer Area6