MediaPortal 2 Weekly snapshot (2015-04-03) (2 Viewers)

[Lehmden]

Hi.

Currently these files are ignored by MP2

This definitely is not the case, I'm absolutely sure. MP2 is using local fanart only. At least if the drive on which they are stored is online while running MP2 client. I can hear the HDD spinning up when fanart is about to be shown. If the Drive (NAS in my case) is offline, MP2 uses downloaded fanart if some is available (not always the case).
In future fanart will be stored in Database, but for now, local fanart is used directly from source without any caching.

 

[MJGraf]

OK, this is a bit unfortunate

I know - that's why it's on my todo list
As an interim solution: If you have nfo-files and local fanart for ALL your movies, you can try to move the MovieMetadataExtractor plugin out of the plugin directory and restart your server / client. Same goes for series and the SeriesMDE plugin. That way these MDEs don't run and nothing will be overwritten.

 

[aspik]

This definitely is not the case, I'm absolutely sure

I’ve done yesterday a test with one movie locally stored on my laptop. I’m pretty sure that the poster which I saved locally was not showed in MP2. MP2 has displayed some other poster. I will do a re-test and report back, maybe I’ve done yesterday something wrong

 

[MrTechno]

Of course you can't always trust local info. Files created by TVE invariably contain bad data (episode titles as part of the description, cover art from a random time offset in the TS)

 

[aspik]

Of course you can't always trust local info. Files created by TVE invariably contain bad data (episode titles as part of the description, cover art from a random time offset in the TS)

After a movie is recorded, and before it’s moved to the movie directory, it will be anyway manually edited (cut offset, rename file, transcode and generate NFO) in this case the file gets for sure the proper data. If the recording is displayed as a .ts file, directly after the recording is finished, it gets the data from EPG and if the EPG gives the file a wrong title, it will get also the wrong data from the online scraper.

 

[breese]

While not a fan of nfo files, I did some testing. This is to possibly help with what is needed when this section is written to correect the Priorities.... Draw from this what you will but I can tell you the curreent system is drawing from multiple locations at the same time.

I deleted the DB, everything in the folders TheMovieDB and Thumbs\FanArt
I then created seperate folders for each of the 5 movies
1941, A Brief History of Time, A Christmas Carol, A Funny Thing Happened on the Way to the Forum, All Quiet on the Western Front

Within each of the Movie folders (except All Quiet on the Western Front)
1941.nfo
backdrop.jpg
folder.jpg

For All Quiet on the Western Front I renamed folder.jpg to All Quiet on the Western Front.jpg

On a fresh import the importer created folders for each movie in C:\ProgramData\Team MediaPortal\MP2-Server\TheMovieDB
Besides the # for TMDB it also created a folder for IMDB because of the tt# listed within the nfo file.
Within each of the TMDB folders (as per the Matches.xml) it created
movie_en.json
Backdrops (with image files)
Posters (with image files)

What gets real interesting is while I had not gone into Movies yet, the folder C:\ProgramData\Team MediaPortal\MP2-Server\Thumbs\FanArt was Empty
The moment I went into Movies, C:\ProgramData\Team MediaPortal\MP2-Server\Thumbs\FanArt was populated with image files AND All Quiet on the Western Front (the one I changed the folder.jpg was different from the others.

Thumbnail_272a73b0-bc0d-4ca0-b498-683dc820bd0d_512x512_All Quiet on the Western Front.jpg
vers
Thumbnail_ec6cf27b-54e0-4dd0-8ef7-7ba6dc3e188b_512x512_folder.jpg

So as it turns out, the CURRENT system is looking at files within the Movie directories yet creates the folders and files within the Standard MP2 directries.

Now durring all this I had MP2-Client running...
I went in and deleted all the files within C:\ProgramData\Team MediaPortal\MP2-Server\Thumbs\FanArt
I then went back into Movies.
This time the system created the FanArt_ec6cf27b-54e0-4dd0-8ef7-7ba6dc3e188b_1920x1080_backdrop.jpg files but NOT the folder image files.

 

[MrTechno]

I record a lot of kids tv series. I'm also lazy and time poor, so.I do the absolute minimum required to the XML files to get an online match. Suspect the prioritisation levels are going to be personal taste

 

[aspik]

Done some more testing... it looks like it also depends on the skin. BlueVision scrapes online the poster, ApollOne and Titanium takes the one locally saved. Fanart is not support by BlueVision and ApolloOne, in Titanium it displays the online screped fanart..

@MJGraf
Thanks for the Tip, as an temp solution its a good workaround. But as you already know, it needs a proper prior solution. As there are currently differences between skins (support fanart) I'm guessing that this depends also on the MIA rework

@MrTechno
If I record something which I'm not planing to add in movies, series or videos I'm not even correct the XML file (not to mention cut offsets). It lies in the recordings section until I'm decide to delete it. You're right, is matter of personal taste

 

[Lehmden]

Hi.

BlueVision scrapes online the poster, ApollOne and Titanium takes the one locally saved. Fanart is not support by BlueVision and ApolloOne, in Titanium it displays the online screped fanart..

I'm using grey theme for BlueVision, but there are no modifications on the fanart handling or other screen related code. Only thing that is changed are the colours.

A sceenshot from movie section while my NAS is running (with local fanart stored on):

And here the same situation with my NAS not running:

So definitely the locally available fanart is used only.

 

[MJGraf]

If I remember correctly (still on Easter vacation - no coding machine around ), the source of fanart used is non-deterministic. We have so called fanart providers, which are kept in a list on the server. If a client asks for fanart, the server iterates through the list and returns the fanart it gets from the first provider that was successful. So depending on which provider was loaded first (which on a gives system 'may' always be the same) it can return fanart from various sources.
I don't like anything that is non deterministic and we could certainly solve that with an extension of the FanartSeevice. But it would be a waste of time. As soon as the MIA rework is ready, there will only be one source for fanart (and, hence, only one fanart provider): our MediaLibrary. That will make it much easier to get deterministic (and potentially configurable) results...