DAc con cubieboard

http://cubieboard.org/2013/10/18/g2-labs-has-released-a-dac-module-for-cubieboard/

PORQUE NO SACAN ESTAS MIERDAS PA LA RASPI??? (aunque ahora saco el sonido por hdmi y tampoco me importa una mierda)

La verdad es que me mola un montón la Cubieboard: tiene puerto SATA, LAN, dos USB, jack para salida de audio...
y además le puedes meter Android o un GNU/Linux normal y corriente.


Me vendría perfecto para ser mi nuevo Media Center. De hecho, estaba contemplando la idea de comprar un pincho
chino de esos con Android, concretamente un Rikomagic IV que cuesta casi lo mismo:

http://www.pccomponentes.com/rikomagic_mk802_iv_16gb_quad_core_android_tv.html


El inconveniente es que la GPU Mali 400 creo que no puede con Full HD (1920x1080), ni en Android ni en GNU/Linux.
De hecho, ni siquiera sé si el driver Mesa (GNU/Linux) que hay para ella soporta OpenGL y decodificación de vídeo
por hardware.

si puede con fullhd...

lo malo de la cubieboard es el consumo... un sata chupa lo suyo.

la raspi puede perfectamente con mkv a 1080 y consume 4W/h... de pico!

Ya te digo q la tengo yo de mediacenter/servidor nfs/cliente torrent/servidor de impresion en 24x7 y funciona de la hostia

alfonskunk escribió:si puede con fullhd...

lo malo de la cubieboard es el consumo... un sata chupa lo suyo.

la raspi puede perfectamente con mkv a 1080 y consume 4W/h... de pico!

Ya te digo q la tengo yo de mediacenter/servidor nfs/cliente torrent/servidor de impresion en 24x7 y funciona de la hostia

Pos no sé qué decirte. Yo he visto ya un montón de vídeos sobre la Pi en Youtube y no me parece que el Full HD se le dé muy fino que digamos. Aunque igual lo que he visto puede que sea antiguo. Ni idea, la verdad.

Y esos MKV de 1080 que mencionas... ¿Tú mismo tienes pelis así?

Y en caso afirmativo: ¿Me dices cuál es -más o menos- el archivo de vídeo más gordo que le has metío pa reproducir?

Ando algo perdido con todo esto, más que nada porque no quiero gastar 100 euracos en algo que no me sirva.

la raspi son 25 pavos... tampoco ibas a perder dinero

Luego te miro bitrate y demas, pero he visto BRay-RIP de esos de 18Gb sin problemas...

ademas, soy mas de series... cada episodio (40min) suelen ser unos 1.8Gb-2.4Gb o algo asi...

eso si, yo tengo compradas las licencias de mpeg y vc1

ademas, la raspi se usa con debian... no te digo na!

alfonskunk escribió:
la raspi son 25 pavos... tampoco ibas a perder dinero

No, colega, la Pi cuesta bastante más que eso: Pi + caja + fuente de alimentación + hub USB...

Solo la Pi ya te cuesta 40 euros:

http://www.pccomponentes.com/raspberry_pi_rev2.html

alfonskunk escribió:
Luego te miro bitrate y demas, pero he visto BRay-RIP de esos de 18Gb sin problemas...

Vale, pero con ese dato (BRrip de 18 GB) ya tengo suficiente. Gracias.

alfonskunk escribió:
ademas, la raspi se usa con debian... no te digo na!

Ya, pero me mola mucho la idea de un Android (Cubieboard 2) con XBMC y un engendro chinorri de estos:

http://www.pccomponentes.com/unotec_flypad_teclado___raton_motion_controller.html

no entiendo xq quieres meter xbmc por encima de la puta mierda de dalvik de android, en lugar de meter xbmc a pelo sobre un debian (sin x ni mierdas en vinagre)

La verdad es q el raspbmc/xbian/openelec van de puta madre (te gustara mas raspbmc q es mas debian pure)

la fuente de alimentacion, si vas a utilizar hdd alimentados a parte, con un puto cargador de movil (microusb) te vale... mejor si es de mas de 1mA, pero vamos, con 700mA vas sobrao...

de hub usb yo tengo uno que me costo 3 pavos, xq va alimentado tambien: 10 puertos... y una sd no es la cosa mas cara del universo... La caja en RS son 6 pavos la bonita pero te la puedes hacer con LEGO, y no es coña...


y vamos, la cubie son 65€ solo la placa... creo q tambien necesita alimentacion, carcasa, sd, etc... vamos, q te sale mas cara si o si

y la cubie lleva ubuntu! (la imagen oficial es lubuntu) jajajaja

alfonskunk escribió:
no entiendo xq quieres meter xbmc por encima de la puta mierda de dalvik de android, en lugar de meter xbmc a pelo sobre un debian (sin x ni mierdas en vinagre)

¿XBMC sin X?

Te reto a que lo hagas:P 


Por cierto: Me he pasaaaaaaaao un montón de horas pa implementar el puto NFS de los huevos en mi microserver. No había leído tanto man uno tras otro en mi vida:

$ man exports
$ man exportfs
$ man showmount
$ man nfsstat
$ man nfs

Y hay otros dos que ya leí en su momento y ahora he pasao de repetir la tortura:

$ man fstab
$ man mount


Nada, que no iba la cosa, y todo por exportar el directorio /media

en el cliente

instala nfs-common, rpcbind y nfs-kernel-server

edita /etc/exports


mete ahi una linea con [NODO A COMPARTIR] [lista de acceso IP](opciones)

reinicia nfs-kernel-server o haz un exportfs -a

en el cliente

instala nfs-common

#mount -t nfs [HOST SERVIDOR]:[NOMBRE DEL NODO COMPARTIDO]



en raspbmc/xbian/openelec se utiliza el X11 embebido en kernel (XFree86) para levantar una minisesion X, pero el Xserver no esta montado... no hay ni rastro de x.org
es la razon por la que funciona tan cojonudisimamente bien

otra cosa es q montes raspbian (el fork debian para la raspi) q ya si q te monta toda la pesca

por cierto, si vas a usar nfs (MUCHISIMO MEJOR QUE LA MIERDA DE SAMBA) acuerdate de usar udp en lugar de tcp (no necesitas gestion de errores a nivel tcp, ya que tienes la gestion a nivel nfs)

y LAS PARTICIONES QUE NO SEAN NI FAT NI NTFS (que son asquerosas)

alfonskunk escribió:por cierto, si vas a usar nfs (MUCHISIMO MEJOR QUE LA MIERDA DE SAMBA) acuerdate de usar udp en lugar de tcp (no necesitas gestion de errores a nivel tcp, ya que tienes la gestion a nivel nfs)

y LAS PARTICIONES QUE NO SEAN NI FAT NI NTFS (que son asquerosas)

Alfonso, yo no uso FAT ni NTFS desde hace años, excepto FAT32 en algún pincho USB, claro.


En cuanto a usar UDP en vez de TCP, pues no me atrevo, el man de nfs habla sobre ello, y pues eso, que no me parece necesario. Es más, creo que NFSv4 ni siquiera soporta UDP (NFSv2 y NFSv3 sí).




En cuanto a la implementación de NFS en el servidor y en el cliente, hace rato que lo tengo:


Servidor:

# aptitude install nfs-kernel-server nfs-common rpcbind


# nano /etc/exports

/media/disco1 10.0.0.0/255.255.255.0(insecure,all_squash,ro,sync,no_subtree_check)
/media/disco2 10.0.0.0/255.255.255.0(insecure,all_squash,ro,sync,no_subtree_check)
/media/disco3 10.0.0.0/255.255.255.0(insecure,all_squash,ro,sync,no_subtree_check)
/media/disco4 10.0.0.0/255.255.255.0(insecure,all_squash,ro,sync,no_subtree_check)

# exportfs -r
# showmount --exports localhost


Cliente:

# aptitude install nfs-common rpcbind


# mkdir /mnt/disco1
# mkdir /mnt/disco2
# mkdir /mnt/disco3
# mkdir /mnt/disco4


# mount -t nfs 10.0.0.100:/media/disco1 /mnt/disco1
# mount -t nfs 10.0.0.100:/media/disco2 /mnt/disco2
# mount -t nfs 10.0.0.100:/media/disco3 /mnt/disco3
# mount -t nfs 10.0.0.100:/media/disco4 /mnt/disco4


El problema lo tuve al pretender exportar el directorio /media, porque si exportas un directorio que contenga puntos de montaje dentro de sí mismo, los archivos que hay en esos puntos de montaje no van a ser accesibles por el cliente NFS. Esto es algo que el man de exports lo deja bien claro, pero se me pasó...




Ahora el inconveniente es el automontaje de esos directorios en el cliente (/etc/fstab):


# nano /etc/fstab
 
10.0.0.100:/media/disco1 /mnt/disco1 nfs defaults,ro,async,nodev,nosuid,noatime,hard,rsize=32768,wsize=32768 0 0
10.0.0.100:/media/disco2 /mnt/disco2 nfs defaults,ro,async,nodev,nosuid,noatime,hard,rsize=32768,wsize=32768 0 0
10.0.0.100:/media/disco3 /mnt/disco3 nfs defaults,ro,async,nodev,nosuid,noatime,hard,rsize=32768,wsize=32768 0 0
10.0.0.100:/media/disco4 /mnt/disco4 nfs defaults,ro,async,nodev,nosuid,noatime,hard,rsize=32768,wsize=32768 0 0


Aún tengo que probarlo, pero ya a priori no me convence. ¿Montar en el cliente a través de fstab? Esto no me parece que sea lo más práctico. Supongo que ahora tendré que pelearme con autofs:

"Autofs controls the operation of the automount daemons. The automount daemons automatically mount filesystems when they are used and unmount them after a period of inactivity. This is done based on a set of pre-configured maps."




Por cierto: Creo que XBMC puede acceder a recursos compartidos NFS sin que tu sistema tenga que haberlos montado antes, es decir: que XBMC los monta al vuelo. Esto lo acabo de hacer con Dolphin (KDE), pero con XBMC no me funciona.

Vale, pues ya lo tengo.

Ahora mi XBMC ya es capaz de acceder al servidor NFS y montar por su puta cuenta mis "exports".


La solución ha consistido en instalar una librería que faltaba en mi sistema y que debería ser una dependencia de XBMC:

# aptitude install libnfs1



NOTA: En el servidor hay que exportar con la opción "insecure", que se refiere a los puertos, y conveniente usar también la opción "all_squash", referente a uid y gid.

Cuidado con los uid y los gid (pasa de los nombres de usuario) que yo la lie una vez con el portatil (que tiene varios usuarios y el mio no es el 1000)

nfs4 funciona sobre udp directamente. TCP hace un control de retransmisiones bidireccional por cada paquete, y es totalmente absurdo en una red LAN, ya que el check del crc de archivo de nfs es inevitable.

Las conexiones TCP para nfs estan "bien" si vas a meter diferentes medios de red entre cliente/servidor... mas que nada por ajuste de mss y ventana...

creeme cuando te hablo de redes y protocolos...de linux no se una mierda, pero llevo 15 años trabajando en redes

alfonskunk escribió:
Cuidado con los uid y los gid (pasa de los nombres de usuario) que yo la lie una vez con el portatil (que tiene varios usuarios y el mio no es el 1000)

Sí, sé que NFS utiliza UIDs y que podrías tener que encarar un inconveniente como este:

- Cliente: usuario "julius" (1000)
- Servidor: usuario "julius" (14578)

Pero para eso están las opciones al exportar "all_squah", "anonuid=xxx" y "anongid=xxx".

De hecho, yo utilizo "all_squah", que convierte el UID del usuario cliente que hace la petición en el del usuario nobody (65534).

Me basta con que ese usuario pueda leer archivos y nada más.

alfonskunk escribió:
nfs4 funciona sobre udp directamente

$ man nfs

"Options for NFS versions 2 and 3 only:

proto=netid The netid determines the transport that is used to communicate with the NFS server.
Available options are udp, udp6, tcp, tcp6, and rdma."


"Options for NFS version 4 only:

proto=netid The netid determines the transport that is used to communicate with the NFS server.
Supported options are tcp, tcp6, and rdma."


Hay una interesante sección en el manual llamada "TRANSPORT METHODS" y, leyendo un poco por encima, pues...
... me conformo con que use TCP para el transporte.

Si yo usara Wi-Fi, quizá me podría interesar forzar la versión de NFS a usar (se puede) junto con UDP para el transporte.





.

Acabo de hacer los montajes mediante /etc/fstab, así cualquier programa tiene acceso de forma transparente.

Además he hecho alguna prueba transfiriendo alguna peli:

- Usando NFS: 70-75 MiB/s.

- Usando FTP: 68-70 MiB/s.

Prácticamente la misma velocidad. 

Con Samba me iba algo más lento que con FTP, aunque entonces no estaba usando un enlace 10/10/1000 como ahora. Flipo que te cagas; me copio una peli de 4 GiB de un puter a otro en un pestañeo. Incluso puede que el límite de velocidad esté ahora mismo impuesto por mis discos duros antes que por la propia red. Madre mía...

haz la prueba... creeme... desmonta una de las unidades y hazla prueba con udp. Si vas a utilizar solo un medio de transporte es absurdo esperar por ACKs y RTM... el medio fisico no te va a cambiar

Si puedes, mira la ocupacion de la red y CPU de los equipos y la diferencia entre tcp y udp...

En un servidor como una raspberry, que tiene poco procesador estoy hablando de un 50% menos de ocupacion...

Vale, haré la prueba lanzando un nmon en el server (por ssh) y otro en el cliente. A ver qué observo...

"nmon is a systems administrator, tuner, benchmark tool. It can display the CPU, memory, network, disks (mini
 graphs or numbers), file systems, NFS, top processes, resources (Linux version & processors) and on Power
 micro-partition information."




De todas formas, me parece que voy a tener que volver atrás y usar SAMBA, o más atrás aún -en el tiempo-
y usar otra vez lo mismo que cuando empecé toda esta historia: MediaTomb (servidor UPnP), o puede que
pruebe MiniDLNA.

Ten en cuenta que la compartición de archivos en sí no es algo que me interese. Yo siempre uso FTP para
transferir archivos, SSH para el control, y luego algo que me sirva para hacer streaming de vídeo. En esto
último es donde entran en juego NFS, SAMBA y UPnp (ó DLNA) para mí.

ahi ya no te puedo ayudar... Yo el streaming de video no lo uso (solo de audio y en modo prueba) porque el servidor es el q tengo echufado a la tele (y no veo nada desde el pc ni desde el movil... musica hice pruebas con DLNA) asi que tengo todo en local. De hecho, ahora mismo, tengo bloqueados los puertos de upnp y dlna en mi lan.

De todas formas, todo streaming de video es udp SIEMPRE. Pero como dices, DLNA/UPNP/RTSP etc son protocolos que no tienen nada que ver ni con CIFS/SAMBA/NFS... simplemente son otros servicios aparte.

SMB es una mierda (el original de Windows) SAMBA es menos mierda pero sigue siendo mierda...

De estos de arriba solo tienes que poner un wireshark en tu lan y ver que hace cuando haces un dir... va actualizando por tcp la informacion entre cliente y servidor haciendo 4 llamadas -y sus correspondientes respuestas- POR CADA FICHERO que haya en el directorio... Por eso es tan extremadamente lento, sobre todo para trabajar con multiples archivos/carpetas. Por ejemplo, en mi caso, mi Fonoteca (donde tengo toda mi musica) es inmanejable con samba... (ojo, samba4 intenta arreglar algo esto, pero sin mucho exito)

CIFS es la misma mierda que lo de arriba pero con gestion remota permisos por medio de AD... no le veo la utilidad para una red local (si es muy potente en un entorno empresarial con AD)

NFS... tu sistema cree que el disco en red es un disco fisico conectado a su nucleo... de hecho, utiliza el SO la misma gestion de ficheros, pero nfs encapsula esa info para redirigirlo a un elemento en red... Luego tiene la ventaja y los inconvenientes de tener un disco duro conectado...

Para hacer streaming tienes q tener muy claro quien va a ser la fuente del mismo y ver como seria la ruta optima para que llegue a todo el mundo. Un servicio de DLNA se puede montar sobre cualquier sistema de archivos (local y/o remoto) Pero tienes que tener en cuenta que si el servidor DLNA tiene el fichero a servir en remoto, este tendra que esperar a tener el control sobre el stream antes de lanzarlo

Si pones esto

SERVIDOR DE FICHEROS <----> SERVIDOR DLNA <----> CLIENTE DLNA

la velocidad de streaming sera la suma de

T peticion clienteD -> servidorD +
T peticion ServidorD -> ServidorF +
T respuesta ServidorF -> ServidorD +
T respuesta ServidorD -> ClienteD

y calcular los protocolos q intervienen en cada caso y el medio de transporte... Obviamente, si tienes una wifi entre el el ServidorD y ServidorF, no utilices UDP, ya que la variabilidad del wifi y su alta tasa de errores va a provocar retransmisiones a cholon (y vas a retrasar el resto)

Sin embargo, el clienteD y ServidorD pueden estar por wifi, ya que, a pesar del udp DLNA tiene un control de flujo (un cacheo) para evitar lag debido a retransmisiones (pseudo-tiempo real) Aun asi, no esperes maravillas (streaming de FullHD+DTS por 802.11g) xq dependes del medio...


Vamos, un carajal!

todo esto para decirte q si vas a hacer mucho streaming, mejor que el servidor tenga los ficheros fuentes en local

y que no tiene nada que ver el streaming con el protocolo de comparticion de ficheros (SMB/NFS) ni con el de transferencia de archivos (FTP/TFTP)... a no ser q los sumes tu (q para hacer DLNA de un video, tenga q acceder a el por NFS)

A ver...

Como ya te dije, yo uso el FTP de toda la vida pa mover archivos daquí pallá y dallí pacá,
y no tengo intención de usar ningún otro protocolo pa esto, ni siquiera el imprescindible SSH
(SFTP en el server junto con sshfs en el cliente, por ejemplo).

Pero luego necesito alguna otra cosa en el servidor que me proporcione streaming (UPnP)
o que lo parezca (SAMBA y NFS), fundamentalmente para el software que instalo en los
clientes: VLC y XBMC.

¿Entiendes ahora mi circunstancia y mi visión -quizá equivocada- en cuanto a este asunto?

Por cierto: Mi colección de pelis/series/música se alberga, evidentemente, en mi servidor.



Por otra parte, me encuentro con un inconveniente: Mis ordenadores clientes no son solo
mi desktop (Debian + VLC + XBMC) y mi media-center (Debian + VLC + XBMC). También
está la tableta Nexus 7 que me he pillao recientemente.

¿A qué inconveniente me refiero? Pues a este, o mejor dicho a estos:

1) Wi-Fi: La Nexus 7 no lleva otra cosa.

2) Android y NFS: Parece que en Android cualquier mierda soporta SAMBA, pero NFS es
otra historia. En cuando a UPnP y su derivado DLNA pues no sé cómo andará la cosa.

Ah...

Acabo de lanzar una instancia de nmon en el server y otra en el cliente para observar el uso de CPU más estadísticas sobre la red en ambas máquinas mientras transfiero una peli de 14 GiB.

TCP versus UDP:

La carga de CPU en el servidor ha sido aproximadamente esta: 85% vs. 62%
La carga de CPU en el cliente ha sido la misma.

También he notado que la cantidad de paquetes recibidos en el servidor baja muuuucho al usar UDP.

PD: El archivo de 14 GiB ha sido transferido desde el servidor hacia el cliente.

PD2: Lo anterior te da la razón. 

.

Boton, no mezcles servicios... Primero planea donde tienes las cosas que vas a utilizar y como se accede a ella. Es lo que trato de decirte

SISTEMA DE GESTION DE ARCHIVOS: (particionado de discos duros y demas) NTFS/EXT
SERVICIOS DE COMPARTICION DE FICHEROS: SAMBA/NFS/CIFS
SERVICIOS DE GESTION DE TRANSFERENCIAS: FTP/SFTP/TFTP
SERVICIOS DE STREAMING: UPNP/DLNA

Lo que quiero decir es que da igual que una carpeta este compartida por NFS con un cliente, desde otro puedes hacerle un FTP y desde otro con SAMBA (claro, q el servidor tiene que atender a esos 3 servicios)
Independientemente de como hagas cosas con los ficheros, tienes un servicio UPNP/DLNA corriendo que esta sirviendo archivos a los clientes. Esos archivos pueden estar en local o en remoto

Se trata de que planifiques bien que necesitas para intentar hacer tu sistema lo mas ligero posible.

Te cuento como tengo montado yo el chiringuito, por ejemplo... y estoy contentisimo

SERVIDOR PRINCIPAL (raspberrypi) (ENCENDIDO 24x7) (ethernet 100mbps)
PC ESCRITORIO (ethernet 1Gbps)
PC PORTATIL (wifi g)
MOVILES ANDROID (wifi n)


1.- GESTION DE FICHEROS
La raspi tiene conectado por USB el megadiscoduro donde tengo todo lo compartido en mi red
corre servicios de NFS/SAMBA para la comparticion
PCEscritorio tiene montada la carpeta compartida por NFSv4 (udp jejeje) siempre. De hecho, desde ahi hago la gestion real del mismo (mover archivos, etc)
PCPortatil tambien puede (no esta en el fstab) acceder por NFS
Los moviles (y los PC en caso de necesitarlo) tienen un acceso por SAMBA en modo SOLO LECTURA (ya que desde los moviles lo utilizo sobre todo para coger musica en local)
En el PCESCRITORIO tengo activado un dropbox cuya "carpeta local" esta en la unidad NFS (al principio estaba en la raspi, pero luego me di cuenta de que tampoco es necesario tenerlo sincronizado todo el rato... solo si lo necesito)

2.- GESTION DE DESCARGAS:
SERVIDOR (raspi) tiene montado un transmission daemon. Desde mi movil y desde el PC de escritorio tengo instalado TRANSMISSION REMOTE para gestionarlo (es mas comodo)... Desde los demas simplemente accedo por web (incluso desde el curro)

Monte en su dia tambien un Jdownloader (parecido) para XBMC, pero me dejaba la raspi tiritando... tampoco lo uso mucho, asi que cuando lo necesito lo hago desde el PCEscritorio


3.- GESTION MULTIMEDIA
Basicamente, el servidor es un XBMC. El 99% de la coleccion de musica/pelis/series esta en local (en el discoduromegatocho o en DVDs)
Tambien es compatible con UPNP/DLNA/AIRPLAY (pa cuando viene mi hermano con el puto iphone) pero no lo uso mucho, la verdad... Si acaso para musica.

Tambien tengo plugins de XMBC para ver cine online directamente...

Controlo XBMC con YATSE desde los moviles (es un puto lujo) o con el mando de la tele por CEC. Tambien puedo controlarlo con su interfaz web desde la LAN (nunca desde fuera)


4.- SERVIDOR DE IMPRESION
Servidor CUPS en SERVIDOR. No me gusta como funciona... imprimir imprime desde cualquier sitio, pero mientras imprime la raspi se queda al 100% de cpu... para las 2 copias anuales q hago, voy a volver a conectarlo al PCEscritorio y compartirlo desde alli)

Y algo mas hare por ahi que ahora no me acuerdo...

ah... la gestion del servidor siempre por ssh


Como te digo, tengo todo centralizado en la raspi, y utilizo distintos protocolos segun la necesidad de cada momento... NO SON INCOMPATIBLES