Skin Based Full Media Flagging - a holdover until the real deal is done

i guess djh will work it out that we dont have to tag it in the credit section, because all information is already right with the new MIP build, there are sections for: movie height, width, channels, codec and so on so the credit tag will be available again^^ because right now the tags in the credit section just brings nothing^^

cheeeeeers

midgetspy Wrote:I know, I currently have an NFO file for every movie but it wasn't generated with MIP. I'm wondering if I will be able to simply scan my media and edit my existing NFOs or whether I will have to configure & use MIP for this.

My problem with this question is I don't know what the point would be. The proposed solution is for MIP to scan your video files and report (by means of flags) the various important pieces of information in the "credits" section of the nfo, and those pieces of information would then be read by the Aeon skin. I guess you could simply type the flags into the credits section, if you wanted, but no other programs are currently available to do this. As such, if you are going to do it all by hand, you may as well use the current solution of renaming video files.

esdubu Wrote:Is this not going to be a problem if the tagging info is stored in the writers part of the nfo, this is what happened with mine

[I MG]http://img144.imageshack.us/img144/1264/screenshot001e.jpg[/img]

I actually like that. I'm not as interested in the writer as I am in the resolution and audio format. Maybe make the field scroll so we can see all the information in it.

I think you guys are worrying too much. I am sure when the skin reads the writter informatiuon it will seperate it.

Basically I assume the skinh will work like this.

Read writer string.

Copy writer sectgion of string to screen in writer section.

Read rest of string and put codecs and info etc in the fields they need to go into.

Just because all that info is in one string does not mean that whole string has to be displaied in teh writer section onscreen.

I am sure you will understand when the new release of the skin is done.

Basically the Writer string is just a holder for information. You can put as much info as you like in it and then the skin will use it as it needs. At the moment the skin uses the whole string for the writer info but thats just how it was meant to work. Now that the string is going to be used for more info the code wil just be re-written to handle multi strings in that one.

Well, we can't have it interfering with the Writer field - not visibly, at least. And as far as I know there's no way of telling XBMC not to display *some* of a returned string. So I'd recommend either using another field that XBMC can read or adding the new info to the existing Writer value, with a shitload of spaces before it so it doesn't display on-screen.

djh_ Wrote:Well, we can't have it interfering with the Writer field - not visibly, at least. And as far as I know there's no way of telling XBMC not to display *some* of a returned string. So I'd recommend either using another field that XBMC can read or adding the new info to the existing Writer value, with a shitload of spaces before it so it doesn't display on-screen.

OK sorry I am unsure how the core of this system works. I assumed that in the skin you could have grabbed the writer field and copy it to a new string before displaying the new string as the writer.

My bad.. Maybe I will find some time in near future to have a look at how the core works. Too much assembly code to write at the moment though to think about looking at C

djh_ Wrote:Well, we can't have it interfering with the Writer field - not visibly, at least. And as far as I know there's no way of telling XBMC not to display *some* of a returned string. So I'd recommend either using another field that XBMC can read or adding the new info to the existing Writer value, with a shitload of spaces before it so it doesn't display on-screen.

digitalhigh has suggested that the 'Studio' field be used instead -

digitalhigh Wrote:I've been going over this in my head all day, what would be best...and I think maybe using the "studio" tag instead of writer would be better, simply because you can still use the studio tag to convey studio information, but you can also keep the writer tag in use when it is used.

I dunno. One minute I think it's a good idea, then I'm not so sure which would be better. I just know it would be cool to have full writer fields for everything as well. I guess if it's just for Serenity, then it would be fine. I think stark uses a similar method to determine studios, so it would probably be easier for DJH to adapt to as well.

How would that work out for you?

This is what it currently looks like -

That'd work.

done.. next rev will have the data in the studio field for movies. shows and episode locations remain as they where.

in addition, the scanner has been updated to calculate the aspect ratio, pull the display ratio from the media and detect widescreen formats based on the display size and not just the (sometimes) compressed size in the container.

format support is expanding to the following that will be in the tags.. i'm hoping this covers the majority of them.
SDi, SDp, 480p, 540p, 576p, 720p, 768p, 1080p, 480i, 540i, 576i, 720i, 768i, 1080i

Exact size matches are first, then display based off whats encoded, then a fallback to standard calculations and "close to" size X for the label.

Very nice fekker. This looks promising.