[mkortstiege]

Not possible at this point. Info is currently only available on the show level.

[ccMatrix]

Not possible at this point. Info is currently only available on the show level.

Is there a ticket/any plan to add this?
http://trac.xbmc.org/ticket/6591 seems to have had a short discussion about it.

The data would be stored in the database for the entire series but exposed for the episodes (and season) listitem as well. There is probably no need to store this per episode or season in the database although Scrubs recently showed that it can happen that a series moves to a different network.

[Gamester17]

Not possible at this point. Info is currently only available on the show level.

Is there a ticket/any plan to add this?
http://trac.xbmc.org/ticket/6591 seems to have had a short discussion about it.

The data would be stored in the database for the entire series but exposed for the episodes (and season) listitem as well. There is probably no need to store this per episode or season in the database although Scrubs recently showed that it can happen that a series moves to a different network.

Best is probably to submit a new separate trac ticket for that specific request

[Elvito]

I don't seem to get this working.

Does the studio tag gets scraped from every scraping engine, or do i need to use a specific one??

[mkortstiege]

I don't seem to get this working.

Does the studio tag gets scraped from every scraping engine, or do i need to use a specific one??

Nope, please use TheTVDB.com to scrape your shows.

Btw, r21036 adds studio information to season/episode level.

[ccMatrix]

Nope, please use TheTVDB.com to scrape your shows.

Btw, r21036 adds studio information to season/episode level.

Thank you very much for adding it. Its great when a show only has one studio. If a show has more than one, then the Studio is e.g. "NBC[CR]ABC" ([CR] is a carriage return). This happens e.g. for Scrubs or Robot Chicken.

This makes it impossible to use something like this, since a filename cannot have a carriage return (on Windows):

Code:

<texture>$INFO[ListItem.Studio,flags/studios/,.png]</texture>

At the moment I can use a boolean condition to work around this:

Code:

<visible>!substring(ListItem.Studio,[CR])</visible>

Any idea on how this could be handled?

[jmarshall]

Does it have a carriage return on thetvdb.com ?

Cheers,
Jonathan

[ccMatrix]

Does it have a carriage return on thetvdb.com ?

Cheers,
Jonathan

thetvdb.com lists it with a pipe in the API <Network>NBC|ABC</Network> and on the webpage NBC|ABC. In the sqlite database it is also a pipe.

But somewhere along the line it seems to be converted into a carriage return since checking for the pipe sign in the skin xml doesn't work while checking for the carriage return does. :confused2:

Even if the conversion wasn't taking place the end-result would be the same since a pipe isn't allowed in filenames on Windows either

[ccMatrix]

Today I started to play around with the clearArt mod and noticed that a similar issue arises there when a show has e.g. a : in the title like "Star Trek: Voyager". Maybe it would be just useful, if for <texture> tags, the skinning engine will strip any of the following invalid path characters from the filename.

Code:

/ \ : * ? "  < > |

I think this solution would be the most useful since this applies to any information and there is no need to do additional filtering of any attribute of listitem etc.

[jmarshall]

Many of those are valid on unix filesystems. Such skin based hacks will NEVER work in all cases, and thus will not be supported. You'll just have to wait for the new library.

[ccMatrix]

Many of those are valid on unix filesystems. Such skin based hacks will NEVER work in all cases, and thus will not be supported. You'll just have to wait for the new library.

What new library and how would that fix this?

<texture> is supposed to load a file from the filesystem - how is sanitizing the input to be a valid filename a hack? Shouldn't there be a way to make sure that a skin can be platform independent (even if that means that some characters aren't allowed although unix filesystem can handle them)? How would stripping out characters, which are invalid on any of the supported platforms not work in all cases? I don't talk about removing these characters from the database or something like that - just removing them in cases where they are used for filenames that aren't possible (on any of the supported platforms). If you are uncomfortable with applying such a filter to any <texture> input, you could also add this as an texture-attribute and leave the decision to apply it to the skinner.

Code:

<texture sanitize="true">$INFO[listitem.ShowTitle,shows/,.png]</texture>

I'm sorry if this seems pushy - I just don't see the reason for not having such a function at this point. I guess that issues like this are one of the reason why skins like Aeon use these hundreds of controls each with their own boolean condition to display studio images.

[jmarshall]

The new library will support more media possibilities - essentially arbitrary additional information will be available to the library.

In my opinion, it's inefficient for the skin to be trying to work around things that aren't currently in XBMC via these sorts of methods. I understand why skinners do it, but also recognise all the cases where it will break.

I'm not completely opposed to some sort of filename sanitizer, but I suspect that anything that's done will be non-trivial. Non-english characters, for instance will require eliminating: Essentially there'd be some simple utf8 -> filesystem-safe ascii. I'd hate to think what some of the asian languages would end up as.

IMO supporting additional (arbitrary) information available via the new library design is a better, more flexible way to go.

I'd also recommend "normalizing" things that you want to use images for. As an example, the genre information on themoviedb.org is essentially useless as it currently is. Compare with thetvdb.com where the genres have been normalized (i.e. a restricted set is available) and it's far more useful for doing things like genre images and the like.

Cheers,
Jonathan