Mi media center - Foro

Aprovechando tu buena predisposición Jesús ...

Sobre a la dependencia o no de GitHub, creo que ya había una versión que te permitia cambiar la url para actualizar desde un website u otro, por si no quieres depender directamente de su web.

La idea de hacerlo desde GitHub (y siento ser pesado al volver a decirlo) es porque una vez hecho el merge con el master (si lo configuramos así, hasta se podrían crear ramas beta, depende de lo que queramos liar), ya pueden tener acceso a los cambios, y no hay que esperar a que realices una versión. Puedes crear versiones directamente si quieres (para eso habría que crear releases especificas para plataformas y no una global como hay ahora), aún usamos muy poquitas funcionalidades de GitHub

La idea que yo tengo se podría encaminar por este orden:

- actualizaciones automáticas, ya sea con el launcher que se montó en este hilo, si no añadir el sistema de conectores que es gemelo al de channels, y dejar las versiones que creas para los cambios de componentes internos de la aplicación.
- mejorar los componentes internos aparte de ver como se podrían gestionar para mejorar que sean multiplataforma, desde la versión de python, librerias, eliminar codigo que está duplicado o no se usa.
- mejorar la gestión de canales, muchas veces falla una web y parece que el plugin no funciona. Por lo que sería mejor mostrar información en vez de una lista en blanco, mejorar los try excepts para evitar los petazos cuando no hace bien el scraper, llevar un contador en la aplicacion por tiempo de si se ha intentado acceder a la web en varias horas y sigue sin funcionar de mostrar otro tipo de error, etc.

Aparte de la idea que comentas de añadir más dispositivos compatibles, el resto de lo que comento ha sido hablado o realizado en algún punto.

Lo cómodo para poder integrar todo (y creo que lo mismo se me está yendo un poco la olla xDD) ya que lo mayoría usamos kodi, es hacer una especie de programa piloto del addon en plan "plugin.video.pelisalacarta" desde el repositorio, así es más fácil.
Una especie de versión 5.x, dejar la actual 4.x actualizando las cosas básicas, y luego ir portando al resto de plataformas.

A ver que opina el resto y como siempre la última palabra la tienes tú

SeiTaN escribió:Sobre a la dependencia o no de GitHub, creo que ya había una versión que te permitia cambiar la url para actualizar desde un website u otro, por si no quieres depender directamente de su web.

La idea de hacerlo desde GitHub (y siento ser pesado al volver a decirlo) es porque una vez hecho el merge con el master (si lo configuramos así, hasta se podrían crear ramas beta, depende de lo que queramos liar), ya pueden tener acceso a los cambios, y no hay que esperar a que realices una versión. Puedes crear versiones directamente si quieres (para eso habría que crear releases especificas para plataformas y no una global como hay ahora), aún usamos muy poquitas funcionalidades de GitHub

GitHub no es una plataforma de publicación, es una plataforma de gestión de código fuente. No es que vea mal que lo use la gente para otras cosas, y no creo que a GitHub le moleste demasiado, pero personalmente prefiero no abusar.

SeiTaN escribió:La idea que yo tengo se podría encaminar por este orden:

- actualizaciones automáticas, ya sea con el launcher que se montó en este hilo, si no añadir el sistema de conectores que es gemelo al de channels, y dejar las versiones que creas para los cambios de componentes internos de la aplicación.
- mejorar los componentes internos aparte de ver como se podrían gestionar para mejorar que sean multiplataforma, desde la versión de python, librerias, eliminar codigo que está duplicado o no se usa.
- mejorar la gestión de canales, muchas veces falla una web y parece que el plugin no funciona. Por lo que sería mejor mostrar información en vez de una lista en blanco, mejorar los try excepts para evitar los petazos cuando no hace bien el scraper, llevar un contador en la aplicacion por tiempo de si se ha intentado acceder a la web en varias horas y sigue sin funcionar de mostrar otro tipo de error, etc.

Aparte de la idea que comentas de añadir más dispositivos compatibles, el resto de lo que comento ha sido hablado o realizado en algún punto.

El plan que propones está bien, aunque yo no le daría mucha importancia al "orden"

Iremos haciendo todo en paralelo, y piensa que a menos que tengas muy claro cómo funcionarán esas nuevas plataformas que vamos a añadir es muy difícil que hagas los componentes "multiplataforma". Por ejemplo, ¿cómo se conecta el guitools con Kivy? ¿o con Engima 2? He estado dos días peleándome con Kivy en Android para darme cuenta de que el log que utilizan tiene algunas pecularidades (sospecho de se trata de un bug incluso).

SeiTaN escribió:Lo cómodo para poder integrar todo (y creo que lo mismo se me está yendo un poco la olla xDD) ya que lo mayoría usamos kodi, es hacer una especie de programa piloto del addon en plan "plugin.video.pelisalacarta" desde el repositorio, así es más fácil.
Una especie de versión 5.x, dejar la actual 4.x actualizando las cosas básicas, y luego ir portando al resto de plataformas.

A ver que opina el resto y como siempre la última palabra la tienes tú

No entiendo bien lo del "piloto".

El directorio "main-classic" tiene el equivalente al directorio "plugin.video.pelisalacarta" para la última versión, haces un enlace simbólico a tu directorio "addons" y puedes usarlo directamente.

jesus escribió:

SeiTaN escribió:Sobre a la dependencia o no de GitHub, creo que ya había una versión que te permitia cambiar la url para actualizar desde un website u otro, por si no quieres depender directamente de su web.

La idea de hacerlo desde GitHub (y siento ser pesado al volver a decirlo) es porque una vez hecho el merge con el master (si lo configuramos así, hasta se podrían crear ramas beta, depende de lo que queramos liar), ya pueden tener acceso a los cambios, y no hay que esperar a que realices una versión. Puedes crear versiones directamente si quieres (para eso habría que crear releases especificas para plataformas y no una global como hay ahora), aún usamos muy poquitas funcionalidades de GitHub

GitHub no es una plataforma de publicación, es una plataforma de gestión de código fuente. No es que vea mal que lo use la gente para otras cosas, y no creo que a GitHub le moleste demasiado, pero personalmente prefiero no abusar.

En nuestro caso no nos hace falta una plataforma de publicación, porque tratamos los ficheros como lo que son, no es un entorno web que necesite un despliegue. Ahora si es por tema de abuso en los accesos, por mi parte doy el asunto por zanjado.

Entonces ¿qué propones para las actualizaciones?
a) ¿se permitiran las actualizaciones como los canales (PR de divadr)?
b) ¿se podrá actualizar todo (desarrollo conjunto de varias personas)?
c) ¿se seguirá usando el sistema actual?
d) otra opción distinta.

jesus escribió:

SeiTaN escribió:La idea que yo tengo se podría encaminar por este orden:

- actualizaciones automáticas, ya sea con el launcher que se montó en este hilo, si no añadir el sistema de conectores que es gemelo al de channels, y dejar las versiones que creas para los cambios de componentes internos de la aplicación.
- mejorar los componentes internos aparte de ver como se podrían gestionar para mejorar que sean multiplataforma, desde la versión de python, librerias, eliminar codigo que está duplicado o no se usa.
- mejorar la gestión de canales, muchas veces falla una web y parece que el plugin no funciona. Por lo que sería mejor mostrar información en vez de una lista en blanco, mejorar los try excepts para evitar los petazos cuando no hace bien el scraper, llevar un contador en la aplicacion por tiempo de si se ha intentado acceder a la web en varias horas y sigue sin funcionar de mostrar otro tipo de error, etc.

Aparte de la idea que comentas de añadir más dispositivos compatibles, el resto de lo que comento ha sido hablado o realizado en algún punto.

El plan que propones está bien, aunque yo no le daría mucha importancia al "orden"

Iremos haciendo todo en paralelo, y piensa que a menos que tengas muy claro cómo funcionarán esas nuevas plataformas que vamos a añadir es muy difícil que hagas los componentes "multiplataforma". Por ejemplo, ¿cómo se conecta el guitools con Kivy? ¿o con Engima 2? He estado dos días peleándome con Kivy en Android para darme cuenta de que el log que utilizan tiene algunas pecularidades (sospecho de se trata de un bug incluso).

"El orden" era por los PR y sus conflictos, intentar evitar problemas que nos estaba causando a los no tan puestos con Git , si va a ser todo en paralelo habrá que empoyar y aprender a base de leches .
Que fuera las actualizaciones lo primero en la lista, es algo que está trayendo mucho de cabeza a los usuarios de a pie, y como el resto de compis intentabamos crear una solución para que todo no recaiga siempre en ti.

No conozco Kivy ni Enigma, divadres sugirió con gran acierto en mi opinión, que si algo no esté implementado o es compatible, que no hiciera nada "return true" al uso xD

jesus escribió:

SeiTaN escribió:Lo cómodo para poder integrar todo (y creo que lo mismo se me está yendo un poco la olla xDD) ya que lo mayoría usamos kodi, es hacer una especie de programa piloto del addon en plan "plugin.video.pelisalacarta" desde el repositorio, así es más fácil.
Una especie de versión 5.x, dejar la actual 4.x actualizando las cosas básicas, y luego ir portando al resto de plataformas.

A ver que opina el resto y como siempre la última palabra la tienes tú

No entiendo bien lo del "piloto".

El directorio "main-classic" tiene el equivalente al directorio "plugin.video.pelisalacarta" para la última versión, haces un enlace simbólico a tu directorio "addons" y puedes usarlo directamente.

Me refería de crear una beta accesible y simple,para que no se pisara con el addon actual, de manera que cualquiera podría probarlo sin tener que modificar ficheros.

SeiTaN escribió:Entonces ¿qué propones para las actualizaciones?
a) ¿se permitiran las actualizaciones como los canales (PR de divadr)?
b) ¿se podrá actualizar todo (desarrollo conjunto de varias personas)?
c) ¿se seguirá usando el sistema actual?
d) otra opción distinta.

Le he estado dando vueltas estos días desde mi agujero, y creo que la solución puede ser la siguiente.

1) Basar las actualizaciones en un servicio como el de kampanita que se ejecute en segundo plano, obviamente distribuido como parte de pelisalacarta. Eso funcionará también en plataformas que no lo permitan fácilmente, como Plex e incluso Android.
2) Cuando se ejecute comprobar una por una las URL de los canales (la que hay en el xml) y la de los conectores (nuevo sistema en el PR 153 de Divadres que también utiliza xml), actualizando los que haya nuevos.
3) Podemos poner algún indicador de qué canales / conectores han sido actualizados al entrar al plugin, algo escueto de tipo "Se han actualizado algunas cosas" que opcionalmente te permita ver el detalle.
4) La actualización del "core" se hará con el sistema actual de publicar versiones en el blog, cada nueva versión incorporará las mejoras que sea pero esto no ocurrirá en segundo plano. Así evitamos que la gente reporte problemas que no podamos localizar en una versión específica, te actualizarás manualmente o desde dentro del plugin al entrar, como hasta ahora.

De esta forma una vez que tengas el plugin instalado puedes añadir o quitar canales de donde quieras, y si el día de mañana Github deja de valer con tener una URL sería suficiente.

Creo que más o menos tenemos todo hecho en diferentes partes, es cuestión de unirlo.

¿Qué opináis?

SeiTaN escribió:

jesus escribió:Iremos haciendo todo en paralelo, y piensa que a menos que tengas muy claro cómo funcionarán esas nuevas plataformas que vamos a añadir es muy difícil que hagas los componentes "multiplataforma". Por ejemplo, ¿cómo se conecta el guitools con Kivy? ¿o con Engima 2? He estado dos días peleándome con Kivy en Android para darme cuenta de que el log que utilizan tiene algunas pecularidades (sospecho de se trata de un bug incluso).

"El orden" era por los PR y sus conflictos, intentar evitar problemas que nos estaba causando a los no tan puestos con Git , si va a ser todo en paralelo habrá que empoyar y aprender a base de leches .
Que fuera las actualizaciones lo primero en la lista, es algo que está trayendo mucho de cabeza a los usuarios de a pie, y como el resto de compis intentabamos crear una solución para que todo no recaiga siempre en ti.

A mí esto del Git no me está dando tantos problemas... y por otra parte me está viniendo muy bien ya que lo estoy incorporando cada vez más en el resto de cosas que hago. Si hay que aprender, aprendamos

Desde luego hacer varias cosas en paralelo no tiene mucho sentido...

SeiTaN escribió:No conozco Kivy ni Enigma, divadres sugirió con gran acierto en mi opinión, que si algo no esté implementado o es compatible, que no hiciera nada "return true" al uso xD

Está claro, pero no me refería a eso.

Lo que quiero decir es que si diseñamos un sistema "abstracto" para hacer algo que luego "implementaremos" en cada plataforma, el diseño tiene que tener en cuenta qué plataformas vas a utilizar.

SeiTaN escribió:

jesus escribió:No entiendo bien lo del "piloto".

Me refería de crear una beta accesible y simple,para que no se pisara con el addon actual, de manera que cualquiera podría probarlo sin tener que modificar ficheros.

Podemos distribuir los ZIP de la rama "develop", algo del tipo "nightly-build" como hace Kodi, generados diariamente o algo así.

Yo proponía la api de GitHub por un tema de velocidad, descargar los SHA de todos los canales con una sola url y buscar diferencias, luego los que sean diferentes, ya los descargaremos para comprobar la versión, eso es bastante mas rápido que 200 peticiones a una url (que aunque no sea la api, sigue siendo GitHub) para descargar todos los XML de los canales y servers para comprobar las versiones

Ahora, si se hace en segundo plano, aunque sea mas lento, tampoco va a ser un problema...

Sí, lo de que sea en un servicio es muy cómodo.

Como no todos los canales estarán en Github, y en el hipotético caso de que Github cambie su política, nos seguirá valiendo.