Messages

Fantastic!  I've had work stuff taking over the last week or so unfortunately, so I still need to dig out and test that patch.  I'm hoping to be freed up in the evenings starting tomorrow, and I'll make that a first priority to support any integration discussions we have this week.  Also looking forward to checking out what you've uploaded... thanks!

The parameter on the vol up/down commands?  I think I did use that, actually, within the interceptor that sends out the additional volume commands.  But I'm not seeing how using the parameter can be a solution in itself, unless the orbiter generating the command was made to use the repeat param.  Am I misunderstanding the suggestion?

For me, the draw of the separate device was that you can configure it separately for each audio device that you want to adjust.  For example, maybe I want to triple the volume adjustment rate for one receiver, and double for another.  I can create two devices from this template, one for receiver A configured with 3x repeats and another for receiver B with 2x repeats.  I'm not sure how that would work if it was rolled into the media plugin, but I might just not be understanding the approach.

edit: BTW, I keep saying device, but I seem to remember implementing this as a plugin for some reason.  As I said, it was quite a while ago.  Hopefully I can dig up the code to shed a little more light on it.

This was a couple of years ago, so I may be forgetting details.  But I believe that I just created a new device template, implemented it in C++, registered to intercept all vol up/down messages (I didn't worry about target device at the time), and repeated them as configured.  I don't recall anything special being done with the media plugin.

I do need to get this working with my 0810 install though, so I will hopefully be digging that back up in the near future.  Assuming it wasn't lost, I'll update this thread if I find anything else that I'm forgetting, and of course will also offer up the code if its useful to anyone.

Another option is to create a new device template that registers as a message interceptor, and then listens for any volume up/down commands for a particular device, and sends out repeats as configured in device data.  I implemented this for 7.10 and it worked well to give me 2.5 db jumps on my IR-integrated receiver rather than 0.5 db.

Personally, I like this approach better because you can use it to decorate any device that needs a volume adjustment, rather than making it part of a particular device.  But I'm not good enough with the system to say which is the 'correct' approach, I just wanted to throw that out there. 

I'm not sure I explained it very well, or I'm not understanding your goals correctly.  I'm not sure where the description of it as a directory-based approach comes from, but it's not necessarily directory based.  You can attach rules to a directory, but you can also put them at the top level and just execute the rule based on a regular expression match.  It's really just an engine wired into UpdateMedia that executes custom logic against media that it matches via regular expression. Isn't that what you need? 

In your case I was thinking a rule for each data source (e.g., "IMDBRule", "TVDB"), which you could apply at the top level (or lower if folks did happen to have a tv directory they wanted to limit it to) for an array of regular expressions to match the various naming schemes you wanted to support.  Any media matching would cause your rule to execute. 

Am I way off base here?  It still seems like a good fit to me.

cool thanks!
im posting my progress here http://wiki.linuxmce.org/index.php/MetaData_Handling#Automatic_File_tagging

I extended UpdateMedia to execute a set of rules for new and existing media files quite a while ago.  Reading that wiki entry, I think that what you're doing could just plug into that.  Details are in this thread: http://forum.linuxmce.org/index.php?topic=7116.0.  Trak ticket: http://svn.linuxmce.org/trac.cgi/ticket/158.

It's sat for a long time because I was told no new features would be considered until 0810 was released.  I'm currently setting up a new build environment and will make sure the patch still works with the latest source.  Then I was planning to see if I can generate any more interest in it by making it easier to add to a live system, create some more useful rules, etc.  I'd be really interested in discussing how we could plug your automatic component in to this system as a rule or a set of rules.

I think the auto-tagging feature that I wrote a while back might fit into this discussion.  It's a framework that allows you to attach rules to a directory level.  A simple example would be tagging all media under your "movies" folder as a movie, and all that contained "720p" in the filename as 720P HD.  The matching rules support regular expressions, and custom rule types can be added by adding a class that implements the rule interface.  (I mention that because it is one way golgoj4's more sophisticated rules mentioned in the OP could be added, and only applied to a certain level of your hierarchy if desired - e.g., under 'tv shows')

There are a couple screenshots of the webadmin interface here: http://forum.linuxmce.org/index.php?topic=7116.msg50212#msg50212.  The patch is in trac, but was created against an early version of 0810 alpha, so it might require some tweaking to apply at this point.  I just thought I'd bring it up in case it applied to what you guys were thinking about here. 

As I understand it, the developers have chosen to pass over it for this release.  Hopefully we will get it reviewed for the next release, but in the meantime the patch is still available on the trac ticket.  I haven't tested it with any recent releases and would welcome any testing as always .

I think that having multiple player options would be a very great feature for LMCE.  I just wanted to suggest  following up with niz23's post at http://forum.linuxmce.org/index.php?topic=9257.msg64724#msg64724 before proceeding with wiring in vlc directly.  I'm not sure what his status is, but that approach sounds to me like an excellent way to integrate multiple players (vlc included), if it works out.

I partially implemented the protocol in Java for a GWT / reverse AJAX proof of concept.  I haven't looked at the code posde suggested so I'm not sure it will offer anything different from that, but I'd be happy to share it if another implementation would be helpful to look at.

The wiki is a good starting point, but to be honest most of what I learned of the protocol came from running through the C++ code.  You mentioned that C++ is not a strong suit, but you'll still probably find reading through some of that code to be helpful (especially that in the DCE folder).  Just my 2 cents

I wish I had an answer for you, but I think at best I just have a similar problem and my workaround to share.  I found my samba transfer speeds from NAS to core over 10/100 to be about 25 mbps, while replacing my core with a windows laptop as the samba client got me about 80 mbps.  I did not bring the issue up here because when I booted an ubuntu live cd on the same laptop I saw the 25 mbps on that as well, and so chalked it up to the linux samba client implementation.

My workaround for most of the issue has been to convert my file server to NFS shares, which resolved my HD playback issues.  However, I still have a samba-only NAS that I have been unable to get acceptable transfer speeds out of. 

Sorry to dig up such an old topic, but I recently looked this thread up to help someone in a similar situation and was appalled to see that I hadn't returned to provide the solution...  I was able to combine the 2 IR codes being used into a single code to allow for discrete inputs.  This works much, much better than the toggle mode I had been using before then.  I added the details to the bottom of this wiki page: http://wiki.linuxmce.org/index.php/TOAD_vs_Discrete_Codes

Just curious, what support needs to be added to LinuxMCE?  I'm using NetGear's MCAB1001 wired MoCA adapter to extend my network, and it's working great.  However, it's transparent to LinuxMCE, so I don't see what the gap is.

Well, if it comes to that you access the MD's tree in the /usr/pluto/diskless/# directory (where # is your MDs device ID).  So something like this to create/edit your hosts file:

Code Select Expand

sudo nano /usr/pluto/diskless/80/etc/hosts
You'll want that file to include this line:

Code Select Expand

192.168.80.1 dcerouter

But like I said, only if it comes to that - this file is supposed to be generated automatically, and if this is necessary it means that the closing quote isn't the whole story for this issue.  In that case it might be safer to wait and get the official fix before you create your MDs.

Edit: Just saw your latest post.  If you decide to proceed, you can try the hosts file fix.  But I'm really out of my depth as far as the MD creation process, and just repeating what possy walked us through in IRC.  You may want to drop in there for help or wait for the official fix.