Raspberry Pi builder

[golgoj4]

I've been making some progress.
I've packaged the qt5 I've built with phonon as a deb and installed that.
qOrbiter runs but I'll have to stub out the AudioVisual Plugin for the moment until I can get it compiled. There have been changes in how plugins do their exporting.

-Coley.

Will phonon even run on the pi?

guess ill find out this weekend

-golgoj4

[coley]

golgoj4 - tbh I don't know if phonon is the right direction for the Pi.
I would have thought QtMultimedia would be the one to use but as that requires Qt5 I wanted to see could we at least get the AV plugin going as is. All I was expecting from phonon was at least what it gives a regular desktop system - it shouldn't care about bcm specifics as the drivers below should handle that.

-Coley.

[coley]

Trying to resurrect this - phenigma how far has your builder progressed - or is it like me - been on hiatus?

-Coley.

[phenigma]

Trying to resurrect this - phenigma how far has your builder progressed - or is it like me - been on hiatus?

-Coley.

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.

Jason.

[golgoj4]

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.

Jason.

In the most non offensive way possible.
I fucking love you man. Awesome stuff. Is there anything outstanding we need to get it integrated so thats pnp?

-golgoj4

ps. qorbiter memory handling has improved a ton thanks to sambuca and possy.

[coley]

Ok cool, with qOrbiter improving - Qt5 getting an offical RC - and omxplayer now having limited trick play I'll have to haul my ass back onto this. I didn't realise how far you had taken it - great stuff, +1 to golgoj4's sentiments.

I just got a tad peeved with everything being in such flux and bumping into walls constantly that I left things to settle - and how they have

-Coley.

[golgoj4]

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=7987&start=50

I / we could more than likely implement this method pretty fast if we are willing to give up some features.

Mainly it appears
-seeking
-timecode

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.

-golgoj4

[tschak909]

yeah, let's just get it working, first.

-Thom

[phenigma]

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.

J.

[phenigma]

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=7987&start=50
I / we could more than likely implement this method pretty fast if we are willing to give up some features.

Mainly it appears
-seeking
-timecode

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.  https://github.com/huceke/omxplayer <- 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: http://wiki.linuxmce.org/index.php/Porting_Raspbian 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

J.

[phenigma]

yeah, let's just get it working, first.

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

J.

[golgoj4]

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

J.

Be nice if unfreeze happened before scale, but ive pretty much given up on that

[tschak909]

phenigma: Talk to me in IRC, I'll help in any way I can.

-Thom

[Marie.O]

It'd be nice if the last 4-5 remaining bugs would be squashed before SCALE, so we could have a release by then.

[phenigma]

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.

J.