Messages

46

Users / Re: Why Do Media Directors Exist?

« on: August 23, 2014, 03:48:40 pm »

As with most media players you can control Raspbmc using upnp control but that does not give you access to all of the XBMC UI. With upnp I can send go to a room with a Raspbmc device and stream some video content to it from my Orbiter, and I can control the playback of that content too - play, pause etc.

I think the most important one is to be able to control the PVR to play tv and record etc since that would be something not possible with only the TV with upnp

47

Users / Re: Why Do Media Directors Exist?

« on: August 23, 2014, 08:34:38 am »

We already support Raspbmc in fact - the only thing on your list we don't have is an XBMC plugin to control Dianemo or the control from an Orbiter. But everything else is there. After all once you add Raspbmc to Rpi you have one of the best full featured & open media players you can buy.

Sounds good. Maybe the QOrbiter or HTML orbiter can be add as a plugin. You mean that you cannot control XMBC from another orbiter? That seems like important to be able to use TV or did you solve that differently?

What is then still missing if those 2 points are added? Maybe rs-232 and usb uirt control support? I suppose squeezeslite is already supported?

48

Users / Re: Why Do Media Directors Exist?

« on: August 22, 2014, 10:54:24 pm »

I was just thinking.... I have no experience with any of the following items but maybe its possible and a good way to tackle the issues from both sides:

* use xbmc as the upnp device/player
* xbmc has the ability of playing liveTV via a PVR backend (mythtv)
* use a xmbc plugin to control linuxmce on screen
* be able to use remotes that come with the / are compatible with xbmc to control xbmc & linuxmce via the plugin
* be able to control xbmc via remote orbiters.

Seems to me the best of both worlds and because since you can 'just' use xmbc you don't have to support the hardware yourself while still being able to use the features discussed above.

49

Users / Re: Why Do Media Directors Exist?

« on: August 22, 2014, 03:40:24 pm »

Well if you want to watch Live TV then you can still watch it via your TV itself using its tuner or an external feed from an STB etc. For VDR/Myth then no you cant watch Live TV streamed directly from either of those servers. However with Myth & VDR (I think its tru for VDR) you can watch your recorded shows via upnp and a media player or SmartTV.

hmm. the whole idea (at least mine  ) is to have all that centered and then stream from one point to the MD's/or other players. Pulling additional cables to tv's is not really an option in my case.

As to wired v wifi - we've found that if you provide enough wifi coverage (ie multiple AP's located throughout your home to make sure coverage is good) then wifi performs well. I would say 95% or more of our installations/users in the last 2-3 years are using wifi because they use smartphones/tablets for their Orbiters.

It's not that I don't trust the coverage or even the reliability with all the neighbor and babymonitor interferences but I personally try to decrease the RF exposure of my kids (wifi/gsm). I read so much about it (http://www.electricsense.com/) that I passed the point that I can just ignore it .

50

Users / Re: Why Do Media Directors Exist?

« on: August 21, 2014, 08:58:45 pm »

I really like the way you are going with it and have 2 questions that come to mind.

First is the same that I asked in the power saving topic I started and similar to possy's remark: is it possible to watch live mythtv that way (and control recordings etc, I have my tuners in my core).

Secondly I personally try to avoid wifi and have everything wired. Are there cheap solutions to have a fixed orbiter and are there remote like controllers (I currently have a gyration and a mele F10) that can still be used?

51

Developers / Re: squeezelite as an alternative to squeezeslave

« on: August 17, 2014, 12:11:32 pm »

Code: [Select]

/usr/pluto/bin# cat LaunchSqueezelite.sh
#!/bin/bash
. /usr/pluto/bin/Config_Ops.sh
. /usr/pluto/bin/pluto.func
. /usr/pluto/bin/LockUtils.sh
. /usr/pluto/bin/SQL_Ops.sh
. /usr/pluto/bin/Utils.sh

DEVICEDATA_Alsa_Output_Device=74
DEVICEDATA_PULSE_SINK=88
DEVICEDATA_PARAMETERS=139

SQUEEZELITE=squeezelite-i386
SQUEEZELITEDIR=/usr/bin
SERVER=dcerouter
DEVICE=0

if [ ! -f $SQUEEZELITEDIR/$SQUEEZELITE ]; then
  echo "squeezelite binary not found. Downloading it."
  wget --directory-prefix=$SQUEEZELITEDIR http://squeezelite.googlecode.com/files/squeezelite-i386
fi
if [ ! -x $SQUEEZELITEDIR/$SQUEEZELITE ]; then
  echo "squeezelite binary not executable. running chmod u+x"
  chmod u+x $SQUEEZELITEDIR/$SQUEEZELITE
fi
if [ ! -x $SQUEEZELITEDIR/$SQUEEZELITE ]; then
  echo "error: $SQUEEZELITEDIR/$SQUEEZELITE does not exist or is not executable"
  echo "sleeping 10"
  sleep 10
  exit 1
fi

while getopts ":d:r:" optname
  do
    case "$optname" in
      "d")
        DEVICE=$OPTARG
        ;;
      "r")
        SERVER=$OPTARG
        ;;
      *)
        ;;
    esac
  done

Q="
        SELECT MACaddress
        FROM Device
        WHERE PK_Device='$DEVICE'
"
MAC=$(RunSQL "$Q")

Q="
        SELECT Description
        FROM Device
        WHERE PK_Device='$DEVICE'
"
DESCRIPTION=$(RunSQL "$Q")

AUDIO_DEVICE=$(GetDeviceData "$DEVICE" "$DEVICEDATA_Alsa_Output_Device")
PULSE_SINK=$(GetDeviceData "$DEVICE" "$DEVICEDATA_PULSE_SINK")
PARAMS=$(GetDeviceData "$DEVICE" "$DEVICEDATA_PARAMETERS")


PARAMS="";
if [ -n "$AUDIO_DEVICE" ]; then
    PARAMS="$PARAMS -o $AUDIO_DEVICE"
fi
if [ -n "$MAC" ]; then
    PARAMS="$PARAMS -m $MAC"
fi
if [ -n "$SERVER" ]; then
    PARAMS="$PARAMS -s $SERVER"
fi
ENV="";
if [ -n "$PULSE_SINK" ]; then
    ENV="$ENV PULSE_SINK=\"$PULSE_SINK\""
fi
if [ $AUDIO_DEVICE = "pulse" ]; then
    ENV="$ENV PULSE_PROP_OVERRIDE=\"application.name='squeezelite $DEVICE $DESCRIPTION'\""
fi
echo "Starting squeezelite: $ENV $SQUEEZELITEDIR/$SQUEEZELITE $PARAMS -n \"$DEVICE $DESCRIPTION\""
PULSE_SINK="$PULSE_SINK" PULSE_PROP_OVERRIDE="application.name='squeezelite ${DEVICE} ${DESCRIPTION}'" $SQUEEZELITEDIR/$SQUEEZELITE $PARAMS -n "${DEVICE} ${DESCRIPTION}"


52

Developers / redshift support

« on: August 17, 2014, 11:41:11 am »

Do I need a login now to create trac tickets?

I wanted to put in a feature request for redshift. batches:

Code: [Select]

-374
4384
632
631
redshift.sh:

Code: [Select]

#!/bin/bash

. /usr/pluto/bin/Utils.sh

REDSHIFT=/usr/bin/redshift

while getopts ":d:" optname
do
  case "$optname" in
    "d")
       DEVICE=$OPTARG
       ;;
    *)
       ;;
    esac
done


DEVICEDATA_COLORTEMPDAY=322
DEVICEDATA_COLORTEMPNIGHT=323

# get colors from devicetemplate
COLORTEMPDAY=$(GetDeviceData "$DEVICE" "$DEVICEDATA_COLORTEMPDAY")
COLORTEMPNIGHT=$(GetDeviceData "$DEVICE" "$DEVICEDATA_COLORTEMPNIGHT")

DEVICEDATA_LONGITUDE=108
DEVICEDATA_LATITUDE=109

Q="
        SELECT PK_Device
        FROM Device
        WHERE FK_DeviceTemplate='52'
"

EVENTPLUGINID=$(RunSQL "$Q")

LONGITUDE=$(GetDeviceData "$EVENTPLUGINID" "$DEVICEDATA_LONGITUDE")
LATITUDE=$(GetDeviceData "$EVENTPLUGINID" "$DEVICEDATA_LATITUDE")

DISPLAY=:0 $REDSHIFT -l $LONGITUDE:$LATITUDE -t $COLORTEMPDAY:$COLORTEMPNIGHT

Don't know how to add a package to a template so have not added the info package yet (it's in the repos: sudo apt-get install redshift)

53

Users / Re: thinking about new av receiver

« on: August 15, 2014, 12:46:15 pm »

I can't see that working to be honest. But even if it could be made to work the only advantage I can see is that all the signals are transmitted down a single cable. It seems a lot of complexity for no real gain.

Personally I am even happy with a fixed volume on the device and relative software volumes. To me it seems like a huge gain; one utp cable is everywhere (and for people who do not care about wifi disadvantages they even don't need one at all) and pulling tons of cables and possibly introducing additional (sound) hardware and diminished quality (you probably know the requirements for audio cables when used on longer distances) seems like a lot of trouble if it can be done with a bit of software. Of course that first needs to be made ;-). To bad I don't have an IP receiver otherwise I could test it a bit.

54

Users / Re: Power saving topic

« on: August 14, 2014, 07:42:21 am »

Re UPnP Controller @LinuxMCE: As far as I know, the code has not been committed into LinuxMCE atm. I might have missed it, but I do not think so. totallymaxed probably has the definitive answer.

@Andy: do you have a definitive answer? ;-)

55

Users / Re: thinking about new av receiver

« on: August 14, 2014, 07:40:45 am »

...thats the point you can't control the Amp gain levels for discrete channels or pairs of channels especially as the Amp is receiving a 5.1/7.1 signal down the HDMI (I assume?)

Isn't it possible to link the software volume control to the hardware volume control in a sense that when one of the software volume levels is at max level it will increase the hardware volume and decrease the software volume of the other (not being increase) channels so they stay at the same actual audible audio level?

56

Users / Re: thinking about new av receiver

« on: August 13, 2014, 06:17:18 pm »

The problem is that if you inject a 5.1 or 7.1 signal into your Amp over HDMI (or optical, Coax) you have no volume control over the individual channels that make up that signal.

I am using pulseaudio. there you can make a virtual device for each channel and then control the volume of that channel. Off course then you not using the volume of the receiver (maybe with some smart calculation that can be linked together).

57

Users / Re: thinking about new av receiver

« on: August 13, 2014, 06:15:38 pm »

esperanto
Can you please explain this more as i read it you want to use one receiver for multiple areas at the same time and the audio came from a HDMI connection, and have splitted the audio for multiple zones trough the same HDMI cable?

Correct

58

Users / Re: thinking about new av receiver

« on: August 13, 2014, 03:40:29 pm »

esperanto: Why don't you just try out what happens when you do this manually, ie. outside the LinuxMCE scope. And if you have success with it, detail what you've done.

cause I don't have a receiver with ethernet yet (mine are still from the RS-232 age). However on my desktop I use a hdmi cable to my amp which has 7.1 and by selecting a virtual output on my desktop I can select which channel of the 7.1 is playing sound. So if an amp can stream 7.1 / 9.2 then the only question is what is the best way to stream that to the amp and to control and automate that. Starts to sound like a nice feature ;-).

59

Users / Re: thinking about new av receiver

« on: August 13, 2014, 12:49:00 pm »

Is it a problem if the channels and volume are handled by the stream? When a zone is not active the audio for that channel in the stream is just silent although the receiver is on and playing the other channels.

60

Users / Re: thinking about new av receiver

« on: August 13, 2014, 10:53:58 am »

The IP connection on a receiver is just that. Any IP based audio services the Receiver can access itself will output audio to any of the onboard audio outputs that can drive speakers - those audio outputs do not go via the RJ45 network connection.

So some kind of streaming server with multichannels is required on the core? Or does something like that already exist? That software can then present itself as multiple output devices on the core (to which squeezeslave/lite can output) and then combine these outputs into one (multichannel) stream that is played by the receiver. Then on the receiver it gets played on the relevant channels since each channel is linked to a speaker.

Does that make sense?