Universal Media Server | Forum

I've ported pms-mlx on top of Universal Media Server (UMS) and it has become ums-mlx.
MLX stands for Media Library Extension. The sole purpose of this modification is to offer a more powerful way to configure what folders will show up on the renderer and what they will contain while keeping the powerful streaming functionality from UMS.

Download (currently only available for windows)
Code @ GitHub

Features:
- Import video information from e.g. IMDB, TMDB or TheTVDB (extensible through a plugin system)
- Configure what files will show up in a folder by setting conditions (e.g. show all videos starting with 'a' and having the genre 'Action')
- Set the way files will be sorted and named in a folder
- Show files either as single files or with more information in a folder (similar to transcode folder)
- Track the files you've played
- Reworked plugin system

Library:


Movie:


Folders:


Plugins:


Quick start:
- You'll find a new tab called media library
- In the general tab, click on scan folder and add all the folders you want
Now you're all set and can use it with the default configuration.

You can also configure the entire folder structure that will show up on the renderer using about 50 parameters like size, languages, genres, plot...
All existing folders that are known from UMS like the ones configured in shared folders or iTunes are also available.
To add folders as you know them from UMS, go to the Media Library tab -> Tree -> Right-Click on a folder and add a File System Folder.

Nightly build:
Want to always keep up to date? Download the latest nightly build.
From the above link, download ums.jar and copy it to your installation directory.
It is still recommended to install official releases, because it might contain new binaries (e.g. mencoder) and possibly other setting changes when it is being released.

Hope you have fun with it

I've put a new version up on sourceforge: ums-5.2.3-mlx-1.3

Not many changes from the mlx side:
- Improved start/stop playing notifications
- Bundle java in version 8u45 where the JDK is included in the installer

UMS:
- All changes between 5.1.2 and 5.2.3 are included

New version is available on SourceForge: ums-5.3.2-mlx-1.4

Changes:

• General:
  • Added the possibility to show or hide the transcode and live subtitles folders for every media library folder
  • Fixed refreshing of folders when content changed (full rewrite)
  • Update tools to use the same as UMS
  • Cleaned up ums-mlx specific code using an eclipse formatter
  • Multiple minor bug fixes
• User interface:
  • Removed unused configuration properties in 'Navigation/Share Settings' tab
  • Made user interface more responsive by updating the Library view less frequently
• Plugins:
  • Added the possibility to add origninal UMS/PMS plugins of type AdditionalFolder(s)AtRoot to the DLNA tree
  • Jumpy can now be installed with its installer in ums-mlx the same way as for UMS (thanks skeptical!)
  • IMDB import:
    • Fixed plugin by using http://www.omdbapi.com instead of the now obsolete http://www.imdbapi.com

Any feedback is welcome

Hello!

First of all, i have to thank you for your effort on giving some better library-functionalities to the ums. First impressions looks great, i am testing the possibillities actually.

And of course thanks to all the people who bringing ums to the masses too

I dunno if, but hope so that, this is the right place to come up with an plugin request?

I think this could not only be an final solution for the issues with the (currently all non-working) xbmc/kodi-library-plugins on ums, but you may can save some time on inventing extra-complex scrapers too? My Idea:

Is it possible to provide an plugin that will read the infos from seperated .nfo xml-files, which xbmc/kodi can generate (by exporting the video-library to seperat files the .nfo-xml's are generated for each video seperately and are saved in the same location and with the same file-name like the video-files), instead scraping infos from imdb/tvdb/tmdb?

If so, it would be nice to load pictures the same way in addition, i.e. choosing between <video-file>-poster.jpg and <video-file>-thumb.jpg, or first try poster then thumb etc. (And maybe then generating smaller ones from them in the central pic-folder for faster use on the dlna-client, if necessary).

With this it would be somewhat easy for all the xbmc/kodi-users, to use ums instead the built-in UPNP/DLNA-functionalities of xbmc/kodi, which lacks on transcode streams for clients like ps3/xbox etc. What do you think about this?

Thanks for reading anyway

best regards

Hi mediamelt,

This looks pretty simple to do if it respects the format shown here. Could you post some sample NFOs so I can have a look at them?

Sure, with greatest pleasure

Stand by!

Also, @taconaut you've probably seen it already, but there's an outdated pms-xbmc plugin for reading the xbmc/kodi library sql database directly. I don't know the details, but using this approach would presumably bypass the need for intermediate user-generated nfo files and allow MLX to do it automatically .

Hello!

@taconaut:

The content of the nfo-files is exactly the same as shown in the kodi-wiki, plus some additional data (picture-urls mainly). I can confirm that the important tags hasen't changed for a long time, since relevant data like Title, Description, etc., is imported from this nfo's by other mediacenters with old plugins too, i.e. mediaportal.

You can find an sample .nfo for a movie here:
http://pastebin.com/0mxGF2VZ (expire 1 month)

Kodi exports the .nfo and some .jpg's to the same location the video-file is located in. Saying each movie is stored in its own subfolder, after kodi-export the folders content will looks like this:
http://pastebin.com/cuy9gBbA (expire 1 month)

When tv-shows are stored in this structure:

X:/TV-Shows/Name of TV-Show
X:/TV-Shows/Name of TV-Show/Season 1
X:/TV-Shows/Name of TV-Show/Season 1/Videofile.s01e01.avi
...and so on..

Kodi exports an additional .nfo (as well as .jpg's = poster and banner for the tv-show itself and for every season) with information about the show and seasons in the main-folder of tv-show (where the season-folders are located) and then putting seperate .nfo's (and again .jpgs too) for each episode in the season-folders next to the videofiles...

The file-strurcture looks like:
http://pastebin.com/NraPrYUi (expire 1 month)

The whole folder-structure and all the .nfo-files of this sample i have packed for you here (all videos and pictures are removed):
http://www.xup.in/dl,10677538/TV-Shows.zip/ (please notice if file can be removed from hoster)

I hope this can clarify all possible questions for you, if you need further information please don't hesitate to ask for

Thanks a lot!

@infidel:

First, there is also an newer fork of this plugin, the coressponding thread for kodi-ums can be found here:
viewtopic.php?f=6&t=3269 ...

I agree, on first sight it seems, if simply fixing the new kodi-library-importer or old xbmc-library-importer plugins will solve the issue and maybe the kodi-library will be usable again in ums - for a while.

BUT!

This will fix things only as long, as no kodi-developers is touching any structures or namings etc.in the tables at kodi-library or do some other tricks within kodi causing such an plugin to malfunctioning. This was exactly the reason the newer kodi-ums plugin got broke and has stopped working completely after just a few days the plugin was finished (if i remeber right, read the thread). Resulted in leaving the plugin behind and recommend self-fix and rebuild by the Users themselfes .. (And meanwhile, there are numerous other alterations causing endless logs of errors with this plugin?!). Kodi developers seems to love massive alterations on the tables or other important things in kodi

By using the .nfo files this source of error is eliminated, since the structure of .nfo's is still the same, no matter how much the tables on kodi-library was altered by new kodi-versions (as already mentioned above, the structure of .nfo hasen't changed since the times, where kodi was still called xbmc officially, but, the kodi-database is changing literaly with every new version or beta that is released)...

The next thing is: by saving the srcaped data this way, it is not neccessary to keep kodi on the same machine where ums is running nor on the same network nor on the same planet. I.e. you can use nas acessed by one machine running kodi to add new media-files with scraped data in attached .nfo's and another machine running only ums, using the .nfo's instead scraping again (and propably failing to scrape the correct data if scraper runs unattended).

And another thing is: Kodi's nfo-files are not only understood by kodi (and hopefully soon ums-mlx ), they can be used with many other mediacenter-software too, i.e. mediaportal to name some prominent one. In Summary the exported .nfo's can be seen like fail-safe backup and universal exchange-format, it makes things more transparent to understand and easier to use by the costs of only a few megs of diskspace.

Because the MAIN thing is: Only if you using kodis library export to seperate .nfo-files, you nearly can feel almost sure, to never lose any scraped data accidentially again. One pressed button on remote or keyboard in a hurry can be enough, and cleaning databasees is running unintentionally over all the media-files, that is actually unreachable. And believe me this: This will exactly happens to you in that single moment with all your external drives and network-shares are down and you haven't any apropiate backup of kodis library handy.

The big disadvantage of any scraper-plugins on any mediacenter-platform is still this: You can name your files as accurate as you can, but from 1000 scraped movies you have to fix matching manually in at least about 100-150 cases. Even adding the tt-number to the file-name will not do the trick always. When you scraping something other like US-English, this situation turns much worser quickly. You like Japanese or Korean action and horror movies? Bbetter prepare for intense orgys trying to match them! With a huge media-library you always have to fix a relevant amount of matches manually over the time. And you will do THIS! only ONCE! per life-time. Infinite! Exporting to seperate .nfo's set you free from all those exorbitant efforts and timewaste on banalities like filenames Just leave the cryptic scene-dirnames like they are, match unscrapeable mediafiles manually and export into seperated .nfo's to be done with it ONCE! and for ever. No matter if files are moved, kodi is broken, computer is stolen, whatever... Simply reuse already scraped data from .nfo-files with a few clicks at any time ans as often you like. (Re)import Data for GiGs over GiGs in a few minutes into any kodi-, any ums-, any mediaportal-setup or many others too.

The Idea of importing kodi's XML-files directly should make more sense now, i hope. All user would be able, to freely combine the mediahandling-plattforms by themselfes, to fit the own needs perfect and in detail... i.e. using kodi to organize local media and scrape for data.... along with mediaportal for the best stability and experience when watching TV from DVB-S/C Hardware.... finally combined with UMS to serve all the stupid, old, weak mediaplayer-clients, TVs, Reciever etc., as well as Playstations and Xbox360s... scraping data once with kodi, then exchanging the media-library by using kodi's seperate xml-files on all 3 plattforms automaticly .... Not more and not less is the goal

Thank you for participating on discussion

best regards to you guys.

Thanks mediamelt, you've persuaded me that reading the nfo files is the way to go I'll post a plugin here you can test when I'll find the time to write it.

mediamelt wrote:Thank you for participating on discussion

You're welcome, I sure got my money's worth discussion-wise . I have to confess that my entire 'library' is currently one folder with 124 movies, so for me the topic is completely abstract.