Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - phenigma

Pages: 1 ... 58 59 [60] 61 62 ... 103
Developers / Re: New Device Template (Samsung PN-51E 5-Series)
« on: January 27, 2013, 10:22:09 pm »
Hey Dennis,

I did a lot of playing with that script a couple years ago.  It was converted to create a serialized output rather than a .php script sometime before I started playing with it.  In it's last posted form I believe it was working well.  I have used it to move my device templates from system to system during re-installs many times with great success.  It is not a supported method of submitting/moving devices around right now.

It would be great to have the templates submitted to sqlCVS so they would be available for others to use.  Have a look at:


Developers / Re: Raspberry Pi builder
« on: January 27, 2013, 08:51:18 pm »
Clarifying my omxplayer babbling.

When I speak of creating an omx player device for lmce many people seem to think I am talking about a dce wrapper for the console based omxplayer.  This is not what my intentions are. 

omxplayer is essentially a console interface to a statically compiled omx library.  My intention is to port the player portion to dce so that it is a native device like xine, not a console wrapper like mplayer.

:)  Just wanted to clear that up in case there were any misconceptions about my intentions for the device.


Developers / Re: Raspberry Pi builder
« on: January 27, 2013, 02:34:17 am »
It'd be nice if the last 4-5 remaining bugs would be squashed before SCALE, so we could have a release by then.

Yes!  Yes!  :-D  I'll check and see if there's anything there that's within my reach to tackle.


Developers / Re: Raspberry Pi builder
« on: January 25, 2013, 11:25:47 pm »
yeah, let's just get it working, first. :)

:)  Yes, lets! (waiting for freeze lift...)


Developers / Re: Raspberry Pi builder
« on: January 25, 2013, 11:25:03 pm »
I / we could more than likely implement this method pretty fast if we are willing to give up some features.

Mainly it appears

Other than that, this would be pretty brain dead simple to implement. Maybe I should be less of a snob about this and accept that we cant have everything we want for v1 of a video player on the pi.

I don't think we need to sacrifice anything really.  The omxplayer source is available and it implements seeking entirely via timecodes.  If we base from the existing omxplayer then interface is through a static lib (similar to xine), interfacing would be more like xine using function calls rather than parsing text output like mplayer in slave mode.  lmce's omxplayer source could then be easily updated as additional functionality is added to omxplayer to leverage new features from upstream. <- omxplayer source.  To my untrained eye this looks *easy* to port.

I am completely willing to put the work into this as I have really enjoyed bringing this as far as I have.  My hands are tied until freeze is lifted and new devices can be created and sql2cpp run, etc.  It would also be handy for me to have svn access.  Again, until freeze is lifted there is not much I don't see much I can do on the player.

For reference: read along and let me know if there are any questions, that way I can clarify things. 

There are currently 3 aspects that need further investigation:
  • avwizard mods for rpi - haven't looked extensively at this but it is very doable
  • omxplayer - player/plugin creation - waiting for freeze lift before I can continue on this
  • uboot - kernel parameter passing issue, see wiki


Developers / Re: Raspberry Pi builder
« on: January 25, 2013, 11:24:40 pm »
Is there anything outstanding we need to get it integrated so thats pnp?

Yes.  pnp booting also needs tackling, I have been testing two approaches, in the long run uboot is the preferred method. 

There are two options:
1. uboot network boot (preferred)
  - provides complete pnp
  - no user interaction with sdcard contents
  - dd card image once
  - sdcard contents unchanged
  - move the card to a new PI and a new MD will be created.
  - initial boot kernels and MD kernels fully managed by core
2. standard pi boot (not preferred)
  - mostly pnp
  - dd card image
  - sdcard contents change after initial MD creation
  - move the card to a new PI, user must alter sdcard or re-dd image
  - kernels managed entirely on the sd card
  - initial dd images must be updated as kernels change

I was working towards the uboot functionality but uboot has still not matured entirely on the pi.  I need to take another stab at it but much of the functionality for the rpi is still awaiting merge in uboot.  I have been applying patches to the source for testing.  Kernel parameters do not pass consistently with uboot on the pi.  I believe I know the issue but haven't had a chance to implement/test anything.  Essentially there is missing piece of code that copies the aggregated kernel parameters to memory location where the kernel is expecting them to be.


Developers / Re: Raspberry Pi builder
« on: January 18, 2013, 01:59:16 am »
Trying to resurrect this - phenigma how far has your builder progressed - or is it like me - been on hiatus?


Not sure specifically what you mean by how far my builder has progressed?  I had previously built all the packages for raspbian/armhf and they are up at dropbox for use in sources.list.  It has been a few months since I've done a rebuild of those packages but they work just fine with a 1004 core.  I have been puttering away the whole time.

I have a full MD running on 512MB RPi, photo-screensaver and UI1 with USB-UIRT.  Full MD with screensaver crashes on 256mb rpi.  The only piece of the puzzle that is missing is an omxplayer (a la mplayer_player) to handle media playback on the pi.

MD creation is essentially worked out, I have copious notes and have been working on updating scripts for proper MD functionality with as little alterations to current scripts as possible.  I have been waiting for 1004 release and lifting of feature freeze so I can request svn access and update everything I have here into svn.

Talking with golgo we decided that a UI1 based MD on rpi is the way to go until qorbiter matures more.

So... if there is anything that people could/should try to work on it is an omxplayer for pi mds.  With that we would have essentially complete MD functionality on the rpi.


Now to actually put them to some use...  need to use the knowlege a little.  :)


Screencasts are available from now.


Thanks very much coley!

I'm missing: 1,5,6,10,11 From group #1 and I did not even know of the existence of anything in group #2.

Any you could provide would be great!


Are these available anywhere?  The links below aren't working and only half of the screencasts are available at localeconcept...  Thanks.


Developers / Re: qOrbiter gets some Pi
« on: October 21, 2012, 06:22:38 pm »
Super sweet!  You guys rock!


Developers / Re: qOrbiter gets some Pi
« on: October 20, 2012, 03:02:04 am »
Guess I'll have to get a third Pi now to test the extra mem ;)

You and me both.


Forever we have told people DO NOT dist-upgrade. This is an attempt to undo that. I may just write a script that dist upgrades and changes those links if they don't point to the right place.

This should be included as people upgrade so systems are not broken.  dist-upgrade is *required* any time our packages bring in any *new* package.  (my 2 cents)


Pages: 1 ... 58 59 [60] 61 62 ... 103