Search the Community

Hey all, I've noticed something pretty odd happening when I load a new movie and trailer into any of the watched directories. The fetcher always seems to grab data for a 40's Disney short named "Mickey's Trailer" instead of the trailer for the movie the trailer is actually for even though it grabs the data for the movie just fine. This happens if the trailer is in it's own sub-directory under the main movie or if it resides in the same folder as the main movie. Is it my setting or is something odd just happening, any ideas? Thanks

Lately I've noticed something odd when I open the emby apps (WMC, Roku and Andriod). Television titles are now replaced with "<error>" as seen the image attached. Typically, I let Media Center Master do all my fetching before I move something into one of Emby's watched folders but every now and then I forget and just throw something into its folder and just let Embys fetcher do the heavylifting. For whatever reason lately, the fetcher has been showing junk. Any thoughts?

Version 3.0.5404.29588 following on from http://mediabrowser.tv/community/index.php?/topic/6333-artist-name-is-initials-issue/?p=88447 MB3 can not handle artists with ID3 tgs ending in full stop. eg 't.A.T.u.' 2014-10-19 15:20:01.2458 Info - ImageProcessor: Failed to read image header for E:\MediaBrowser\IBN\artists\t.A.T.u\folder.jpg. Doing it the slow way. 2014-10-19 15:20:01.2458 Error - App: Error getting image information for E:\MediaBrowser\IBN\artists\t.A.T.u\folder.jpg Could not find file 'E:\MediaBrowser\IBN\artists\t.A.T.u\folder.jpg'. System.IO.FileNotFoundException at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileInfo.get_Length() at MediaBrowser.Api.Images.ImageService.GetImageInfo(IHasImages item, ItemImageInfo info, Nullable`1 imageIndex) Steps to reproduce. 1. Create W:\Music\t.A.T.u\[insert some album here] (no full stop at end because windows file system doesn't support) MB3 successfully identifies, album/artist and downloads metadata into media collection. 2. Go to metadata manager and change the primary image for the artist. Error as above.no folder.jpg in collection. It is odd that on first fetch MB3 handles the artist but cant handle manually fetching artwork from metadata manager.

Hi Luke, perhaps not the highest priority issue, but none the less here goes... Version 3.0.5099.2102 i dont know if if was ever a design goal..but it always used to be the case that the entire media browser system could be rebuilt quickly from metadata stored in the collection. If all else failed, the mb3 library/data/config folders could be deleted (i.e. everything), mb3 reinstalled, and MB3 would rebuild itself respecting all personalised changes from metadata stored in the collections. This is now no longer the case for music and movie backdrops I think. Steps to reproduce. (MB3 configured to store metadata in collections) 1. remove all mb3 appdata (data/cache/library/ibn artists backdrops) 2. remove all music backdrops in the collection. 3. install mb3 and let mb3 download music backdrops. 4. let system stabilise/download all metadata (including metadata populated in collection and ibn\artists) (Now we have a totally consistent healthy environment built afresh for music backdrops- i assume) 5. delete library DB and restart MB3 (to perform a full rebuild from cached metadata or otherwise) (an artificial action perhaps, but none the less one that used to 'work' in MB2) 6. Duplicate music backdrops are now populated in the artist folders / music collection. (presumably because mb3 cant be sure where the locally stored backdrops (from the 1st library build/fetch) in the collection came from) I dont know if you would classify this as an issue? but maybe to ensure robust consistency during rebuilds it could be a development suggestion to Ensure the record of what backdrops are downloaded/identified from what online and local sources are populated robustly across all relevant datasources/records ie appdata\? AND in the collection artist.xml So that during a rebuild, the music metadata (backdrops) stored in the collection are identifiable and not duplicated. Likewise movie backdrop images are also duplicated after a library deletion/then rebuild, perhaps the movie xml could also keep a record of backdrop download sources/content as well. or alternative simpler suggestion maybe more simply once backdrops (or perhaps all image metadata) are fetched and at least one exists in collection, then no more are fetched unless the user expressly chooses an option to remove that image metadata and refetch from online sources. TV doesnt seem to duplicate backdrop images in collection after a library rebuild. perhaps a crc checker could always re-associate a locally sourced backdrop with an online provider during such a rebuild if this level of sophistication was deemed necessary - but maybe the alternative suggestion above is good enough.. what are your thoughts on the subject?