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 - Esperanto

Pages: [1] 2 3 ... 17
1
Users / Re: extra drive in core 12.04
« on: September 01, 2014, 03:44:20 pm »
Yes, thats how I also ended up fixing it. All content lost though.. I think the issue was that a swap partition did not have a UUID.

If someone else also as an issue with a drive that does not get detected first check if it has a uuid:
Code: [Select]
sudo blkid

2
Users / extra drive in core 12.04
« on: August 26, 2014, 12:27:20 pm »
Anybody knows what might cause this bug to occur:

http://trac.linuxmce.org/trac/ticket/2140

Possy saids he has extra drives running without issues which seems strange if that ticket is valid.

3
Users / Re: Why Do Media Directors Exist?
« on: August 25, 2014, 08:17:20 am »
In these situations just place a small 4-port switch in the room behind your TV etc and the connect your devices to the switch. A switch is super reliable, low cost and very low energy. We'be used this config in 100's of professional installations and it has proven to work well and be incredibly reliable.

Maybe I am misunderstanding you. I have UTP cables on the different locations. No coax though. and neither do I have extra PVR's / STBs. Those all bring extra complexity, costs, power and possible points of failure usage I supposed.

4
Users / Re: Why Do Media Directors Exist?
« on: August 25, 2014, 08:15:04 am »
No media director? No Game Player. but it seems, I'm the only one who gives a shit about that...

will that run on the raspberry pi ?

5
Users / Re: Why Do Media Directors Exist?
« on: August 24, 2014, 10:38:27 am »
Oh we do that too. We support IP control of SmartTV's and PVR/STB's, we also support CEC control over IP of TV's too. None of that requires any MD's at all.

As said before. I only have UTP cable to the different locations. If you replace the MD by PVR/STB and cables then you increasing complexity and costs instead of decreasing it imho. Even though then the MD might fail I have more trust in something open then the closed smarttv, PVR/STB. Especially if it is possible to have _one_ cheap but fully working solution so all use the same. I still feel the core needs to have all connections directly feed into it and there need to be light players/controllers that can actually be controlled (like also softwarewise) whatever that might be ;-).

6
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

7
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?

8
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.

9
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  :D) 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 ;).

10
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?

11
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}"

12
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)

13
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.

14
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? ;-)

15
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?

Pages: [1] 2 3 ... 17