Messages

31

Developers / Re: Android application as a device

« on: December 04, 2012, 01:01:20 am »

ah yes, I remember now.  Its not quite finished.  I hadn't decided whether to stick with the compile against database approach used in the normal C++ devices (so you have constants matched with IDs in your source code generated from the database), or whether to load them at runtime.
Anyway, its not in a slick, finished state.

32

Developers / Re: Android application as a device

« on: December 04, 2012, 12:58:17 am »

Hey, not been around for ages.

There's a probably working Java DCE implementation here

https://github.com/dawsonsystems/JavaDCE

And a half built Java DCE device here  -> https://github.com/dawsonsystems/linuxmceagent

I'm not quite in a position to pick this up, but if anyone is interested, it'd be a good motivation to get myself set up again. My linux mce project died a death when my little girl started walking.  Now she's in nursery...  well, the possibilities open up a little again.

33

Users / Ortek MCE alike remote

« on: April 30, 2012, 01:25:42 am »

Howdy.

I bought a remote from maplin the other day and wasn't watching too closely. So I ended up with a maplin branded 'Vista MCE Remote' that is actually an Ortek VRC-1100 in drag.
Rather than return it, I thought I'd try to get the thing working with LMCE.

Following instructions found here --> http://wiki.xbmc.org/index.php?title=HOW-TO:Configure_VRC-1100_remote_for_Ubuntu
I've got commands coming through in irw from the remote nicely, although the update was a little invasive (adding udev rules, installing inputlirc)

However, actually getting the wee beastie to control the orbiter on the core is another matter.  I've tried various things, but nothing seems to have any particular effect, so I'm at a loss where to properly start..

Also, a 'USB Game Pad Remote' is being continually installed. and re-installed with a few minutes if I remove it, anything to do with this?

David

34

Developers / Re: #1438: Make qOrbiter Play Media - Scope request

« on: April 24, 2012, 04:43:19 pm »

Also, because I like to make people's lives hard, I have some quick questions if you dont mind.

*How do you view the path of cross compiling qt (necessitas) vs flushing out the JavaDCE?
*Do you envision a method the two apps could talk to each other. Is there some type of interface i would need to provide on the Qt side?

The main thrust of the questions is I like to have a big picture view of things in my head. With desktop variants, i have a fairly defined idea of the involved parts. Android is still something thats in flux from that perspective and im just wondering if its time to start learning some java on my end.

Thanks for all your hard work on this and qOrbiter, its really appreciated.
-golgoj4

Howdy.  Congrats on the job!!

Not sure what you mean by flushing out?

As for comms.  dunno really. maybe via DCE?   It might be cool to have that anyway so that qorbiter can be embedded/ controller in a media director.  might be a similar interface.  Not sure I'm getting where you're going .... ;-)

I wrote this to run on desktop ubuntu.  I wasn't really thinking much further along than that, although given the correct dll for libvlc, it'd work on windows too with no modification.
It was me playing at an implementation for the 'desktop agent' that thshak has mentioned that we looked at a while ago.   

Once this is done though, and it media wise it can be controlled via the orbiters, and you add qorbiter into the bundle, it does seem a pretty good addition.

David

35

Developers / Re: #1438: Make qOrbiter Play Media - Scope request

« on: April 24, 2012, 12:44:57 am »

Java DCE Implementation.

https://github.com/dawsonsystems/JavaDCE

Functional (and suprisingly slim!), but very hardcoded on event/ command ids.  Not something I want to keep and as soon as I can, I'll break that to make the lib agnostic to the ids that are present in the current system

This is inspired by a bit of code that someone at pluto wrote and then documented to an extent.  I forget the exact details, but I rewrote the lot in late 2010/ 2011 before life sent me south for a year.


Simple device that will boot and then sit in the taskbar doing nothing.

https://github.com/dawsonsystems/linuxmceagent

• Presents a UPnP interface to act as a Media Renderer, built using the Cling library
• Presents a DCE interface to play media.
• Uses libvlc (via a snazzy java wrapper) to do fullscreen video playback
• Has a simple java based image viewer for static pictures, so can display those to

The UPnp implementation is full of holes.  The DCE implementation only has one function, to play media.
The device template I'm going for implements the "Media Player Commands" and "Smart Media Player" command groups. Thats the idea anyway.
Currently it only responds to 'Play media' (37) when you pass it a MediaURL.

This is all dreadfully hard coded and semi developed... so please don't think it will work (esp the libvlc compilation, as i did it myself and its not very likely to function anywhere else than ubuntu 64 bit)

Anywho.  for those who are interested, I will continue development on my github account.

36

Developers / Re: #1438: Make qOrbiter Play Media - Scope request

« on: April 22, 2012, 06:19:07 pm »

Good good.
I'll clean it up and put it on github when I get a moment, sometime in the next few days.

37

Developers / Re: #1438: Make qOrbiter Play Media - Scope request

« on: April 20, 2012, 10:56:21 pm »

Oh, I'd be happy to share or contribute that if you think it may be useful.

I'm a java dev, so the language choice came naturally, C++ still isn't really comfortable for me.   

That said, I'm not offended if not, I know this is C++ project.. 

:-)

38

Developers / Re: #1438: Make qOrbiter Play Media - Scope request

« on: April 20, 2012, 10:54:12 pm »

Might it not be more appropriate to have a second, media playing device that happens to be bundled with many (/ most) qorbiter installs?

That way you aren't giving qorbiter to much to do, and could have completely seperate implementations for android, desktop etc.

I had fun a wee or so ago prototyping a java based app using libvlc that could do that job (its presenting UPnP Media Renderer and basic DCE interfaces at the mo, and plays any media I have when passed an MRL, which is all of it as its on a UPnP accessible NAS).

Kind of clunky, but it did highlight that a simple media playing device doesn't appear to be that involved compared to the likes of qorbiter, as it just isn't doing a lot in comparison.

Dunno, am I talking crap?

39

Developers / Re: Solicitation for Development: Desktop / Workstation Agent

« on: February 07, 2012, 05:33:18 pm »

oooh.  I understand now.

Right, well, that sounds very nice indeed.

40

Developers / Re: Solicitation for Development: Desktop / Workstation Agent

« on: February 07, 2012, 12:07:11 pm »

Heh, wasn't clear.

Basically, one thing I'd like to be able to do cleanly is to watch CCTV and videos on my handset controlled via the orbiter interface. 

This seems to be a similar idea to the workstation agent (although it would obviously need a significantly different set of tech, probably for each device type)

David.

41

Developers / Re: Solicitation for Development: Desktop / Workstation Agent

« on: February 07, 2012, 11:53:03 am »

Hello. posting to old thread for fun and profit.

Did this go anywhere?

I like the idea as I understand it.

It'd be very cool to take that idea and apply it to the mobile devices qorbiter is being ported too as well desktops.

Eg, on an android handset, have a video/ CCTV be able to be accessed/ controlled via the qorbiter interface.

42

Developers / Re: Spotify device

« on: February 06, 2012, 11:43:41 am »

Hi,

I would put the device on the core if it does not really need to be on the MD.
I would always try to expose the audio as a stream, this allows us to seamlessly send audio to both squeezeboxes and MDs.
There is a spotify library iirc? Is that what you intend to use. Either way, it should be possible to implement several spotify clients within the same Spotify device, right? So it might not be necessary with several devices.

If possible, I'd use xine to play the stream on MDs, and then there be no reason for the spotify device to be on the MD itself. All of this is depending upon a spotify device that allows us to access the audio stream in some way, ofcourse.

Don't know the exact process of adding screens, but they need to be added in the Screen table in the database. I think this is used, at least as reference, in qOrbiter too.
After adding an entry in the table, and committing it to sqlCVS, you go ahead create a new Screen_xx.xml file in qOrbiter (from how I understand qOrbiter).

br,
sambuca

Yes, I'm planning to use libspotify.

Apparently libspotify delivers audio as PCM data.  I suppose that this will need to be converted to proper digital in some way and wrapped in some streaming protocol to make it network accessible (any idea?). 
hmm, sounds a fair sized task. Thats definitely my aim though, anything else seems weak.

On using xine.  I suppose that there would need to be some scenario set up that would startup the spotify stream and direct xine to play from that.  So the constraint on the network format is really what xine can consume (and what the squeezeboxes can support, and my ability to convert PCM data to a network stream, blah).
This is something I'm interested in, how would the architecture of that hang together?   I mean, on the orbiter I'd press a button that will trigger a scenario (I imagine) that will send a command to both the spotify device and a xine device on a particular MD.  Right?

I like the multiple accounts within a single device.  I'll work towards that I think.

If I wanted to direct the audio across multiple media directors/ zones, how would the scenarios work for that?

Sorry for mixing a few idiot questions in.  I'm still full of holes when it comes to how bits of the system work (learning fast though :-))

David.

43

Developers / Spotify device

« on: February 06, 2012, 11:00:21 am »

Howdy.

So, following on from my foray into qOrbiter, I'd like to have a crack at a DCE device proper.   As I've wittered on at length about on the dev IRC, I'd like to make a device that can play spotify stream music and control it via qorbiter.

Before embarking on a coding adventure (some time later this month or likely in March), I'm gathering some information on what approaches to take. So, a few questions if anyone has an idea.

Spotify is based on user accounts.  I'd like to be able to have multiple devices to play differnt music in different areas, but that requires more than one spotify account. We have 2 accounrs, one for me and one for my wife.  So that fits into a device per user model, but I'm not sure if thats the best model.  You can't have a single user account in use by more than 1 device at a time.

My questions :-

• Where should this device live (core, media director), and should I have it being a device per user account?
  
• Might there be a way to have the device on the core, and expose the audio as a network stream?  If this is possible, it'd be cool, as then non media directors could tap into the stream, and stream could be played over multiple zones from the same device.
• Is there a preferred mechanism to output sound (eg, alsa, phonon etc)?  (although some networked solution does seem preferable...)
  
• This is going to need a UI in the orbiter.  I've no real interest in adding to the current orbiter, only qorbiter.  Given that, whats the outline of the process to add a totally new set of screens? small single numbers thereof. (feel free to RTFM me on this if there's an entry somewhere I haven't found yet)

So, any ideas welcome.

David.

44

Developers / Re: Translating GUI Tool

« on: January 30, 2012, 06:10:00 pm »

The jar is a bit odd, but doesn't look malicious at first glance.   
It appears to be the mysql JDBC driver jar with a few classes added to provide the GUI.  (the manifest gives this away). 

Gmail believes its clean.

I've inspected the code via decompilation, and it looks clean.  standard java Swing gui code.

I haven't gone through all the bundled mysql classes, however.

Might I suggest reworking this into webstart?  its not too much work, gives you an easy method to update the tool and lets you split the app up into jar files, so the mysql driver could live by itself again.

45

Developers / Re: Translating GUI Tool

« on: January 30, 2012, 05:56:01 pm »

Surely the easiest way to verify would be to provide the source code.