Plugin: Web User Interface for SageTV 2.2-6.6 (V2.25 18 Sep 2009)

[Khristopher]

For anyone interested......Opera Mobile properly shows the menu bar from the Web Interface (and it works too).

[robgfaulkner]

Originally Posted by bcjenkins

so.. If you can use relative pathing for the web server why not put it in a dir on the webserver and use a pointer to it?

B

Because then EVERYONE would be running around with NON-STANDARD Web Servers, and next time Nielm did a fix, they would ALL be broken!

Which, is umm, as you know, not the way software is supposed to work.

-Rob

[bcjenkins]

Sorry for sounding dense, but if the proposal is to replace a class file that someone edited because it has a pointer to a missing file; how is this bad?

The next time Nielm does an update and replaces the class file, the worst thing which will happen is you have a dtd file floating in the webserver root or subdir. It won't necessarily be used by anyone, right?

B

[kricker]

I am confused as well. Why can it not just point to the .dtd that is already in the Sage folder? Is that file on the web constantly updated in someway?

What does the .dtd file do anyway?

[bcjenkins]

http://www.xmlfiles.com/dtd/

B

[robgfaulkner]

Originally Posted by bcjenkins

http://www.xmlfiles.com/dtd/

B

Guys, when the XML file is generated, internally, it puts the DTD <!DOCTYPE tag into the XML. This tag, tells any and all parsers, how to validate the fields(tags) as it parses. If it is missing, those parsers generate an error. Try viewing one of your XML files inside Internet Explorer and see what happens. It won't display, it instead returns an error. Therefore, almost all parsers fail, because they cannot find the DTD to do the validation. Mainly, because all parsers use the standard DOM XML components.

Now, this XML is generated by the SageTV server, using the sageshowinfo DTD. It is produced inside a class, in the SageTV Webserver .jars. It points to a standard location for the DTD on www.sage-community.org. Which is down. Therefore, all XML files generated won't parse and those importers written to work with sageTV are broken. Everyone installs sageTV into a different place, therefore, its not just a simple put the sageshowinfo DTD into a certain location, because the parser has to know the EXACT location. Therefore, the class that generates the XML file, needs to know this location, and put it in the <!DOCTYPE tag line, and this location needs to be accessible for the parser, and for any other tools that expect to parse the XML.

Just having a bunch of people manually decompile their JARs and changing code and doing a recompile is not the solution. And, most people will NOT have the training to understand how to do this.

-Rob

[bcjenkins]

I still don't see an answer to my question in your answer.

If you use a relative path, the webserver jar file has to assume a current working directory to interpret it. If it is a relative web url then the end user is already running the web server component and can it can be relative to webroot. Doesn't seem too complex to me.

Or is the issue when some other application wants to consume the output of the xml data and needs the interpreter? In that case you would need a fully qualified URL path, but why not make that a property and be done with it?

B

[sojourner753]

Originally Posted by Khristopher

For anyone interested......Opera Mobile properly shows the menu bar from the Web Interface (and it works too).

Have you tried Netfront?

[Jason]

Originally Posted by robgfaulkner

Guys, when the XML file is generated, internally, it puts the DTD <!DOCTYPE tag into the XML. This tag, tells any and all parsers, how to validate the fields(tags) as it parses. If it is missing, those parsers generate an error. Try viewing one of your XML files inside Internet Explorer and see what happens. It won't display, it instead returns an error. Therefore, almost all parsers fail, because they cannot find the DTD to do the validation. Mainly, because all parsers use the standard DOM XML components.

Now, this XML is generated by the SageTV server, using the sageshowinfo DTD. It is produced inside a class, in the SageTV Webserver .jars. It points to a standard location for the DTD on www.sage-community.org. Which is down. Therefore, all XML files generated won't parse and those importers written to work with sageTV are broken. Everyone installs sageTV into a different place, therefore, its not just a simple put the sageshowinfo DTD into a certain location, because the parser has to know the EXACT location. Therefore, the class that generates the XML file, needs to know this location, and put it in the <!DOCTYPE tag line, and this location needs to be accessible for the parser, and for any other tools that expect to parse the XML.

Just having a bunch of people manually decompile their JARs and changing code and doing a recompile is not the solution. And, most people will NOT have the training to understand how to do this.

-Rob

Can you change the .jar file to the following location...?

http://tools.assembla.com/sageplugin...owinfo_1_2.dtd

or
http://sageplugins.cvs.sourceforge.n...geshowinfo.dtd

The WIKI is hosted on another server for right now/ever...(?) Nielm?

-Jason

[AngelofDeth]

The latest webserver requires java 1.5/6? That is unfortunate, as java 1.6 causes my MVP to run like mud. (at least it did the last time I tried it)

[bcjenkins]

Hi nielm,

Running linux

1) conflictIcon.gif should be renamed to conflicticon.gif to match the source
2) When trying to use conflict resolution there is an exception thrown.

Exception while processing servlet:
java.lang.NullPointerException
java.lang.NullPointerException
	at net.sf.sageplugins.sageutils.SageApi.IntApi(SageApi.java:129)
	at net.sf.sageplugins.webserver.ConflictsServlet.doServletGet(ConflictsServlet.java:76)
	at net.sf.sageplugins.webserver.SageServlet.doGet(SageServlet.java:82)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at Acme.Serve.ServeConnection.runServlet(Serve.java:1501)
	at Acme.Serve.ServeConnection.parseRequest(Serve.java:1476)
	at Acme.Serve.ServeConnection.run(Serve.java:1363)
	at java.lang.Thread.run(Unknown Source)

In this particular case the reason for the conflict is because the channel is no longer in the lineup.

B

[mclement60]

When I click on stream to wvx it opens windows media player and play video but no audio.

Tried VLC but stream is to choppy.

Thanks

[nielm]

Originally Posted by robgfaulkner

This tag, tells any and all parsers, how to validate the fields(tags) as it parses. If it is missing, those parsers generate an error.

What should actually happen is that the program running the parser looks at the PUBLIC doctype ("-//NIELM//DTD SAGESHOWINFO XML 1.2//EN"), understands what this means, and points the parser to a local copy of the DTD that it knows about (in XML terminology, this is a custom EntityResolver). This is what my webserver does when importing the XML. The URL to the DTD is a fallback mode...

Anyway, I have contacted the owner of www.sage-community.org, told him that his DNS is screwed, and I will release a newer version of the webserver and XML plugins with the DTD hosted on Sourceforge...

[nielm]

Originally Posted by AngelofDeth

The latest webserver requires java 1.5/6?

No, it should run on Java 1.4 (odd that you get a slowdown: 1.6 gives most people performance benefits over 1.4)

[bcjenkins]

Originally Posted by nielm

What should actually happen is that the program running the parser looks at the PUBLIC doctype ("-//NIELM//DTD SAGESHOWINFO XML 1.2//EN"), understands what this means, and points the parser to a local copy of the DTD that it knows about (in XML terminology, this is a custom EntityResolver). This is what my webserver does when importing the XML. The URL to the DTD is a fallback mode...

Anyway, I have contacted the owner of www.sage-community.org, told him that his DNS is screwed, and I will release a newer version of the webserver and XML plugins with the DTD hosted on Sourceforge...

So since it was having an issue, is it a case sensitivity one?

B

[kricker]

Originally Posted by nielm

What should actually happen is that the program running the parser looks at the PUBLIC doctype ("-//NIELM//DTD SAGESHOWINFO XML 1.2//EN"), understands what this means, and points the parser to a local copy of the DTD that it knows about (in XML terminology, this is a custom EntityResolver). This is what my webserver does when importing the XML. The URL to the DTD is a fallback mode...

Anyway, I have contacted the owner of www.sage-community.org, told him that his DNS is screwed, and I will release a newer version of the webserver and XML plugins with the DTD hosted on Sourceforge...

What if the DTD on Sourceforge goes missing? You say the URL to the DTD is a fallback.....does that mean it should be using the local .DTD in the root Sage folder, and only use the web version if the local is missing?

[AngelofDeth]

Originally Posted by nielm

No, it should run on Java 1.4 (odd that you get a slowdown: 1.6 gives most people performance benefits over 1.4)

Yes, it is odd. Maybe has to do with the fact I run win2k3, but I know others run 1.6 fine with Sage on it... When I install the webserver, the server runs but it won't accept a login. I've installed the webserver before, never had a problem getting it to work.

[alon24]

Hi,
I used the export favorites, and tv shows to xml using the webserver, then I delted the wiz.bin and imported all the favorites and shows back.

The favorites are back great, and the shows seem to be there, and running, except that the timelline is corrupt.

It starts with a red bar (from 37 mins or 50 mins) and then a green bar with the correct amout of time.

But it will not save the position if I stop it, and it does show the red bar at the begining so something is worng.

Any idea how to fix all of my recordings?

Thanks

[nielm]

Originally Posted by kricker

What if the DTD on Sourceforge goes missing? You say the URL to the DTD is a fallback.....does that mean it should be using the local .DTD in the root Sage folder, and only use the web version if the local is missing?

yes... kind of.

As far as I understand it (and I am far from an XML expert), any application that understands a certain type of XML should include that DTD internally to the app, so that it does not need to access any externally hosted DTDs when parsing...

When the XML parser is started and its sees it needs a DTD, the app can point the parser to it's local copy of the DTD via an entity resolver so that the parser does not need to read the DTD from the URL.

Eg: Every XHTML web page has a DTD ID and URL pointing to a W3 server, but every web browser does not need to hit the W3 server each time it needs to parse a web page.

[sainswor99]

Originally Posted by nielm

yes... kind of.

As far as I understand it (and I am far from an XML expert), any application that understands a certain type of XML should include that DTD internally to the app, so that it does not need to access any externally hosted DTDs when parsing...

When the XML parser is started and its sees it needs a DTD, the app can point the parser to it's local copy of the DTD via an entity resolver so that the parser does not need to read the DTD from the URL.

Eg: Every XHTML web page has a DTD ID and URL pointing to a W3 server, but every web browser does not need to hit the W3 server each time it needs to parse a web page.

I'm also not an XML expert, but I do know you can embed the DTD inside the XML document itself, which may solve the whole problem altogether. http://www.w3schools.com/dtd/dtd_intro.asp