Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Gedeon]

In the DLNA server, optionally, add a small set of "dummy" entries which purpose would be to perform small, but useful, server tasks, like shutdown and restart, run autoimport, and even small config options like changing the title format among a predefined or an user set of expressions, so renders can get different title based sorting criteria.

[JimH]

In the DLNA server, optionally, add a small set of "dummy" entries which purpose would be to perform small, but useful, server tasks, like shutdown and restart, run autoimport, and even small config options like changing the title format among a predefined or an user set of expressions, so renders can get different title based sorting criteria.

Panel has some of these capabilities.  It's built into MC.

[Gedeon]

Panel has some of these capabilities.  It's built into MC.

Glad to know, I'll test it, However I still think it would be a handy feature for boxes and smart TV's. In 3-4 clicks, without leaving the DLNA browser you can get useful/common things easily done.

[RoderickGI]

In the DLNA server, optionally, add a small set of "dummy" entries which purpose would be to perform small, but useful, server tasks, like shutdown and restart, run autoimport,

In the Navigation Pane on the left > Services & Plug-ins > Scheduler. Check out what it can do. With a command line, MC24.exe and /MCC commands, it can do quite a lot.

[Gedeon]

In the Navigation Pane on the left > Services & Plug-ins > Scheduler. Check out what it can do. With a command line, MC24.exe and /MCC commands, it can do quite a lot.

Those could be triggered from a simple DLNA client/browser. just like choosing a movie or an audio track to be played ? Because that's the feature I'm proposing. So, added to DLNA views, just like categories, years, albums, interpreters, we had a new one called "Server Management" with entries, whick would invoke, not a file/track… but would be received by the MC DLNA server as "messages" to trigger those functions.

[JimH]

Before we continue the discussion, could you investigate Panel?  When you have it running, click on the Settings icon in the upper right corner and then on System Settings at the bottom.

[AndrewFG]

In the DLNA server, optionally, add a small set of "dummy" entries which purpose would be to perform small, but useful, server tasks, like shutdown and restart, run autoimport, and even small config options like changing the title format among a predefined or an user set of expressions, so renders can get different title based sorting criteria.

Look at the MC Web Services Interface. (Jim does mention his fave Panel app which does implement a very small subset of the Web Services, but there are dozens of functions in all, and you can access them all yourself via WSDL commands..)

https://wiki.jriver.com/index.php/Web_Service_Interface

[Gedeon]

Before we continue the discussion, could you investigate Panel?  When you have it running, click on the Settings icon in the upper right corner and then on System Settings at the bottom.

I'm using a linux server right now, I only see "Network", to show info or to scan wifi, no more options.

In any case, for my family it could be great to get those options in the same DLNA browser. Having to switch to a web browser wouldn't be my first option to show my wife and son how to shutdown the server.

Not a dealbreaker, but a suggestion to improve usability for "non inititated" users.

[JimH]

What version of MC?

[Gedeon]

Build 24.0.74 (64 bits) over Ubuntu

[Gedeon]

Any planned update about this ?

[Gedeon]

Kodi DLNA clients don't parse well all the provided metadata by JRiver servers. At least the <year> TAG which now should be <premiered>.

I think It could be easily fixed just adding <premiered> and, maybe other updated mames/tags.

https://kodi.wiki/view/NFO_files/Movies

Could It be updated ?
Is It something I could do as user just adding a new field expecting It will be automatically shared through DLNA by JRiver ?

[LawrenceP]

Pre-Order the V.25 last month.

The V.24 for me so far only have 2 sizeable issue.

1st when song file name has anything other than English characters, your M3U playlist creator will go crazy and skip the non-English character parts of the song file.

Most music players now will be able to find non-English character files on M3U playlist files.

I hope this will be addressed on version 25 since although I don't have a much Chinese song, I do have a lot of Europe(something like this: " ü " will make the program go crazy) and Japanese titles which are difficult to convert them into English characters name.

2nd It seems like the sync to the device is kind of broken when syncing to phone or DAP. I understand some phone will put a restriction of what kind of files its allow to transfer through the USB connection, will that be easier like the iSyncer that they make a little Android app that regulated the phone side files management?? Because today if I try to sync DSD files onto my Galaxy S9 Plus, the MC24 will crash. However, as before I use iSyncer with their apps to regulating the files in the receiving device, it can sync anything there even format the phone can't play. And asking us to convert DSD into another format to sync to a device on Android is kind of Unforgiven. This is the reason most music lover ditch iPhone and buys Android devices anyways. And if I can sync everything into a USB SSD first and copy it to the device without the phone tell me is not support, it should be a way to do it with device sync I suppose. Hopefully, the V25 will have ways to bypass this issue.

[RoderickGI]

Is It something I could do as user just adding a new field expecting It will be automatically shared through DLNA by JRiver ?

Yes. At least I believe it will be shared, as DLNA is a file based delivery method. Try it.

You could create a [Premiered] field, make it a calculated field with the expression "[Year]" (without quotes) and it would be auto-populated from the [Year] field.

But you should ask why Kodi is using the Premiered field. Is it new? Is it standard? Will it work in other configurations and setups? If you use other DLNA Clients, will it work? Will it cause issues anywhere?

The Date and Year fields used in metadata are all pretty well established. You may want to look into what and why Kodi is doing what you describe.



As for your original question, your first post postulated a solution to a requirement you have, rather than describing the requirement properly. Panel may be part of the solution in time, for Linux.

Why don't you have a go at describing your requirement without discussing possible solutions, and also describe your environment more fully, such as Linux server, Windows Clients, Remotes used, etc. You may get more of a response then.

[Gedeon]

Focused in DLNA metadata (Premiered instead of Year), I've done some test and I haven't been able to achieve anything. It seems that JRiver isn't able to send Kodi client that info in the way Kodi expect it, at least just creating a field in the library. I've tested about 4 different formats.

In any case I can confirm that Kodi is able to get the correct info if Kodi upnp client/renderer browses another Kodi instance running as upnp server from a third computer. It just means that Kodi asks through upnp for that info and Kodi upnp servers answer in the correct way. All through upnp/dlna protocol.

I think It can't be very difficult to add this metadata Kodi info asks for as new "content properties" in the JRiver DLNA server, but I don't know the low level details.

Kodi is, probably, one of the most popular client/renderer in small boxes nowadays around the world.

[RoderickGI]

You can't seriously expect JRiver to change MC so that it meets Kodi's requirements, can you? They are competitive products.

I'm sure MC provides metadata via DLNA according to the standard. But I am no expert either. However, playing from one MC instance to another via DLNA (not using Client/Server) seems to share metadata just fine. Just like Kodi playing from one instance to another.

I don't mean to fob you off, but how about you get Kodi to change the way it asks for and handles metadata it receives? I would think the metadata handling was more about the client than the server. You said yourself, Kodi doesn't parse the data well.

Kodi DLNA clients don't parse well all the provided metadata by JRiver servers. At least the <year> TAG which now should be <premiered>.
https://kodi.wiki/view/NFO_files/Movies

Also in the page you provided a link to, Kodi said;
"<year></year>     Replaced by <premiered> tag, but exists for compatibility with older versions. Use <premiered> instead"

So it seems that Kodi should handle the [Year] field correctly, and interpret it as the Release Year. Note also that the [Year] tag is actually an integer in both MC and Kodi by the look of the format, so the correct date field to use for [Premiered] is actually the [Date (release)], which is specifically the date released. The data formats would then match between MC and Kodi. See the format used in Kodi for the Premiered field:
<premiered></premiered>   No   No   Release date. Format as 2019-01-31

One thing I neglected to mention in my last post that you could try is to have the [Premiered] field saved to the file. When you created a new field that wouldn't have been the default. For Movies, this would mean it is saved to the MC Sidecar file. My understanding is that any DLNA client should be able to read tags in the files that are delivered to it, but I don't know what happens with MC Sidecar and Kodi NFO files when a movie is being served to a DLNA client. Maybe you should try your new [Premiered] field based on the MC [Date (release)], and make sure the tag is saved to the file is possible, and see if Kodi can read that?


Basically, tagging between two different applications is pretty hit and miss except for the main tags like name/title. There will always be differences, because there is no real standard, only defacto standards created by individual software providers. For example, my Sony TV acting as a DLNA Renderer only shows the title, and no more. However, DLNA is a standard, and if that is followed, metadata should be presented between DLNA Server and Clients regardless of the supplier of each. The Client just needs to know which metadata to ask for.

[Gedeon]

Absolutely yes, I can ask JRiver to implement/update its DLNA server to accept those DLNA requests. Mainly because JRiver is already able to answer through DLNA metadata like posters, genres, and size,...

Does it mean JRiver should implement it ? Let them answer to this request.

It doesn't seem a bad idea to  improve a strong point (the server).  I don't want to open a discussion about Kodi Vs JRiver, but if you don't have a video rendering product in the small boxes arena Kodi doesn't compete with you. And in any case making your product more compatible isn't a bad business, IMHO.

Greetings!

[RoderickGI]

Well, as I think you realise, I don't work for JRiver, so I'll leave it to them to respond further.

But my point was that I suspect MC is doing everything correctly, and that it is Kodi that has made a change which is non-standard elsewhere.

[Matt]

Do you have any more details on this?  Thanks for any help.

[Gedeon]

First, thanks a lot for your interest.

Regarding to Kodi-metadata requests.

The info I'm able to give is that Kodi, when working as DLNA/upnp server is able to answer to other Kodi clients (accessng Kodi server just like a upnp/DLNA client, not using mysql or file sharing) lots of metadata. That's totally logical, obviously, nothing special.

But JRiver when playing the role as DLNA server is also able to answer certain metadata to Kodi without issues. At least: Title, Genre(s) and Director.  That's which makes me think that it's just a matter of some work to admit a few more formated requests and adding new metadata structures to the already answered metadata by JRiver the DLNA server, since, as I've said some already work.

Since Kodi is open source you can check this file, where the routines to get that inf from XML structures are written. You can find that genre(s) is there, also director, hence, I think with a little more debug info It shouldn't be very difficult to add premiered, studio, country, actors, and maybe more metadata in the way Kodi could parse without issues.

https://github.com/xbmc/xbmc/blob/master/xbmc/video/VideoInfoTag.cpp

To be honest I don't know the low level details, I mean I don't know if DLNA metadata request is just one XML answer/file for each movie/file, or Kodi launches one DLNA request to the server for each kind of "possible" metadata available. I guess JRives accomplishes this document (or higher version http://upnp.org/resources/documents/UPnP_AV_tutorial_July2014.pdf) in which standards are defined, and high chances Kodi has added/changed some of those, but "respecting" the protocol basis.

This seems the core Kodi file with the upnp routines to populate metadata:

https://github.com/xbmc/xbmc/blob/master/xbmc/network/upnp/UPnPInternal.cpp

As far as I'm able to understand it seems that tag info is loaded from one xml file through URL (but I could be totally wrong since my cpp is long  forgotten), in such case, maybe adding a few more xml tags to the standard xml tag answser could work, just a guess.


And regarding to the dummy DLNA control entries.

Just add elements (like view/branches) with no real access to any media item or folder, just to launch/trigger some basic maintenance utils like: shutdown, restart, run-autoimport now,... and maybe more. When a dlna client opens or renders those items (which could be shown as folders, not single items) the server would trigger that actions and would show in t he renderer the content of the "false folder", showing the results "items" like...."Ok" ... "Shutting down in 5 seconds" or messages like those. It could be more than enought to perform "easy" tasks withouth having to use a browser. In my opinion it could be really useful from TV's, cell phones, etc...

Thanks again.

[Gedeon]

Any decision about putting time in this ?

Thanks.

[blgentry]

Why bother with both JRiver and Kodi?  Why not just use the files directly in Kodi from a network share?  Easy peasy.  Done.

Brian.

[Gedeon]

Of course it could work, but not really interested in dealing with double scrapping and some kind of double library management. In such case... why bother to use JRiver for movies ?

[blgentry]

Exactly.  Why use both?  Presumably you like Kodi better for video, so just use Kodi for video.  Use MC for audio.  Best of both worlds for you perhaps.

Brian.

[Gedeon]

As I've said I like Kodi for movie rendering in small boxes (like 95% of small boxes users, that's what I think ). But JRiver has a true potential to work as some kind of "universal home media server". So I could get the same view/trees/contents/behaviour no matter if I access from a PC, a Smart TV, a Cell phone or. a small TV box.

In any case time/resources are always limited. It's up to JRiver team to choose where to put those.

[blgentry]

Oh yeah, you *did* say that about Kodi.  I had conveniently forgotten.  . Sorry about that.  My aim in most of these discussions is to simplify things and reduce the effort required to get to a good solution.  My efforts might have been off the mark here.  Good luck with your setup.

For what it's worth, I currently import all of my movies and TV shows into MC *and* Kodi.  Separately.  But they both find very similar information and both do it pretty well.  Well... as long as I have the files named correctly for Kodi.  MC is a LOT better about letting the user choose what movie or TV show they really mean.  ...and of course MC lets you edit titles (names of movies) and all of that stuff with nearly zero effort.  Kodi is sorely lacking in that department.  But as long as the files are named nicely (which many times I do using MC's rename move and copy files tool), Kodi tends to pick the correct movie title and all is well.  It's only a little bit of extra effort for me.

Brian.

[Gedeon]

To be totally honest and, for God's sake, and not trying to attack to anyone, sometimes I don't understand so many efforts trying to convince other users/customers that they could be wrong, or those ideas don't worth the effort, or that hey should forget about their petitions...

Of course I could be wrong, of course there could be other features more "profitable" for JRiver team to put time in. But they should establish those priorities.

Moving in bad direction or implementing a non very interesting feature is never as worse as not doing almost anything or keeping the product in some kind of stagnation.

Thanks for reading.

[blgentry]

I don't work for JRiver in any capacity.  I'm just a guy that knows something about JRiver MC.  Sorry if my posts seemed wrong or inappropriate to you.

Brian.

[Gedeon]

Sorry if I've left you that impression. That's my fault. Apologies.

I just think that with "the correct" improvements (that qualification it's only JRiver''s prerogative, not ours) they could increase their customer base and adding reasons to existing customers in keeping using their product as the home media environments evolve. My lan/gadgets aren't the same than 6-7 years ago.

Cheers.