Mi media center - Foro

¿Y q problema ves a que las opciones sean configurables? Mira mi primer mensaje en este hilo.

No es que le vea problema, pero con un channelselector dinamico, que sentido tiene actualizar los canales al entrar al canal?
que pasara con los canales nuevos? o un canal que no funciona y esta desactivado?
nunca entraremos, y por lo tanto nunca se descargaran.

Pues yo no veo claro el tener q calcular el sha1 de varias maneras por q no todos los sistemas lo hacen igual (o eso entendi de un mensaje tuyo anterior). Otra opcion es mediante la fecha del archivo. Con una sola llamada tambien se pueden obtener las fechas de modificacion de toda la carpeta channels en github:
Si la fecha del canal W en el github es posterior a la fecha de mismo canal en mi carpeta de channels local, significa q ha sido actualizado.

Lo de calcular el SHA1 con varios métodos, es un problema de los saltos de línea, pero eso seria fácilmente solucionable, si se suben a github todos los canales con los saltos de línea iguales...
lo de comprobarlo por fecha nunca me ha acabado de convencer, ya que no tengo muy claro que pasa con la fecha del archivo al descomprimir o instalar el plugin, se mantiene la original? en todas las plataformas?

Lo de calcular el SHA1 con varios métodos, es un problema de los saltos de línea, pero eso seria fácilmente solucionable, si se suben a github todos los canales con los saltos de línea iguales...

Yo mismo me corrijo, no hace falta calcular varios, el problema es que yo uso git en Windows, y lo tenia mal configurado, no me mantenía los saltos de línea tal como están en el servidor, sino que los pasaba al formato Windows "CRLF" de ahí que no me coincidieran los hashes... una vez configurado bien git, con solo calcular el Sha1 una vez coincide...

divadr escribió: que sentido tiene actualizar los canales al entrar al canal?

Se q es un caso muy especifico, pero te cuento: Cuando no estoy en casa tiro del internet compartido del movil , evidentemente no para ver video, pero si para seguir modificando canales u otras partes del addon. Con 1,2Gb de datos he de ir ahorrando trafico superfluo y actualizar los canales al inicio me repercute negativamente.

divadr escribió:que pasara con los canales nuevos?

Me repito, pero segun la configuracion del usuario. AL inicio comprueba si existen canales nuevos en el github y dependiendo de la configuracion los descarga o no.

divadr escribió:o un canal que no funciona y esta desactivado?
nunca entraremos, y por lo tanto nunca se descargaran.

Esto habria q aclararlo entre todos ¿quien desactiva los canales?¿como queremos q se comporten las actualizaciones con estos canales?:

• Se dasactiva desde el github mediante una actualizacion del canal: En este caso tienes razon, si despues sacamos otra actualizacion 'activa' el usuario no se va a enterar.
• Se desactiva modificando el json local. Es decir, yo modifico mi canal.json por q no me gusta ese canal: Segun tu ¿cada nueva actualizacion de ese canal se me ha de descargar y he de volver a editar el canal.json?

divadr escribió:lo de comprobarlo por fecha nunca me ha acabado de convencer, ya que no tengo muy claro que pasa con la fecha del archivo al descomprimir o instalar el plugin, se mantiene la original? en todas las plataformas?

Partimos de la base de q al comparar fechas si y solo si la fecha en local es mas antigua q la fecha del github se actualiza el fichero local.
Yo tampoco se como se van a comportar todas las plataformas pero entiendo q ha de ser uno de estos casos:

• Al descomprimir la fecha de creacion de los archivos locales corresponde con la de creacion de los archivos en github (recordar q el zip sale de github): En este caso al comparar fechas como las dos son las mismas no pasara nada.
• Al descomprimir la fecha de creacion de los archivos locales corresponde a la fecha de creacion del zip. Como el zip se crea despues que los archivos q lo componen, la fecha de los archivos locales sera posterior a sus correspondientes en github, por lo q no pasara nada.
• Al descomprimir la fecha de creacion de los archivos locales corresponde al instante en q se descomprime. Que evidentemente es posterior a la fecha de creacion de los archivos en github, por lo q nuevamente no pasara nada.

Personalmente creo q este ultimo caso es el mas normal ya q en realidad estamos creando los ficheros al descomprimirlos, por lo q esta debe ser su fecha de creacion.

divadr escribió:lo tenia mal configurado, no me mantenía los saltos de línea tal como están en el servidor, sino que los pasaba al formato Windows "CRLF" de ahí que no me coincidieran los hashes.

Pues si tu lo tenias mal apuesta q yo tb lo tengo mal.
Ademas el sistema del SHA1 te indica que han habido modificaciones, pero no cual de los dos es mas reciente.

Saludos

Ademas el sistema del SHA1 te indica que han habido modificaciones, pero no cual de los dos es mas reciente.

Bueno, yo doy por echo que el de GitHub es siempre el mas reciente

Se q es un caso muy especifico, pero te cuento: Cuando no estoy en casa tiro del internet compartido del movil , evidentemente no para ver video, pero si para seguir modificando canales u otras partes del addon. Con 1,2Gb de datos he de ir ahorrando trafico superfluo y actualizar los canales al inicio me repercute negativamente.

Si descargamos al inicio solo se hace una sola petición a GitHub, donde se recibe un json con los sha1 de todos los canales, a no ser que haya algún canal nuevo que actualizar, los datos consumidos son prácticamente nada y a demás siempre se pueden desactivar las actualizaciones...
pero bueno, se pueden añadir opciones y que cada cual elija la que mas le guste.

•Al descomprimir la fecha de creacion de los archivos locales corresponde al instante en q se descomprime. Que evidentemente es posterior a la fecha de creacion de los archivos en github, por lo q nuevamente no pasara nada.

En este caso, si hay canales actualizados entre la fecha de creación del zip y de la fecha que se descomprime, no se actualizaría, ya que la fecha del archivo seria mayor que la de GitHub, aunque en realidad la fecha real del archivo seria mas antigua.

para mi creo que es mejor comprobar los SHA1 o bien el número de versión... pero la fecha no me parece muy buena opción...

Siempre he defendido el debate por que considero q asi aprendemos todos y esto es una prueba de ello.

divadr escribió: si hay canales actualizados entre la fecha de creación del zip y de la fecha que se descomprime, no se actualizaría, ya que la fecha del archivo seria mayor que la de GitHub, aunque en realidad la fecha real del archivo seria mas antigua.

Tienes razon, no habia pensado esa posibilidad. Descartado el metodo de las fechas.

divadr escribió:Bueno, yo doy por echo que el de GitHub es siempre el mas reciente

En esto no estoy tan de acuerdo, normalmente cuando alguien avisa en el foro de q un canal ha dejado de funcionar publicamos una actualizacion en el mismo foro y despues hacemos un pull request q puede tardar dias (ojo q no es una queja!!! ) en ser mergeada (y disponible publicamente).
No veo muy claro el tema de dos carpetas con canales uno oficiales/publicos y otros modificados/privados. Sobretodo cuando hay dos versiones del mismo canal ¿que pasara con las series añadidas en la biblioteca?

Propongo un sistema mixto: al inicio se descarga el json con los SHA1 de todos los canales y si alguno difiere con los obtenidos localmente se comprueban las versiones de los json y se obra en consecuencia. De este modo no es necesario leer todos los canal.json remotos y podremos estar seguros q actualizamos siempre a un numero de version mayor . ¿q os parece?

Personalmente... me parece la mejor opcion...

super_berny escribió: En esto no estoy tan de acuerdo, normalmente cuando alguien avisa en el foro de q un canal ha dejado de funcionar publicamos una actualizacion en el mismo foro y despues hacemos un pull request q puede tardar dias (ojo q no es una queja!!! ) en ser mergeada (y disponible publicamente).
No veo muy claro el tema de dos carpetas con canales uno oficiales/publicos y otros modificados/privados. Sobretodo cuando hay dos versiones del mismo canal ¿que pasara con las series añadidas en la biblioteca?

Si un canal no funciona y se sube una versión en el foro (y posteriormente en GitHub), esto va en "channels", cuando se suba a GitHub se actualizará ese canal.

Como dijo divadr:

Los canales personales o versiones de pruebas que hagamos nosotros iria en "channels/personal" que esto no se machacaría nunca, y siempre se mostrarían si existen con el mismo nombre que en la carpeta "channels"


Caso 1:
channels/seriesblanco

Se muestra el canal.

Caso 2:
channels/seriesblanco
channels/personal/seriesblanco

se muestra el de la carpeta personal.

En los dos casos se actualiza el canal que está dentro de "channels" si hay versión nueva en GitHub

Saludos.

He estado pensando yo... y si en lugar de comprobar el sha1 y luego la version del canal... comprobamos el sha1 del json? Si ha cambiado el json es porque ha cambiado la version no? De este modo al calcular el sha1 de un archivo mas pequeño tardara menos y ya nos serviria, No?

Y si el json ha cambado... se descarga el json nuevo + py...

divadr escribió:Si hay un canal que en el repositorio no está -> lo borra

El tema de eliminar archivos locales (canales) por decisión de terceros no me gusta nada.
Tampoco tener que tener una carpeta "personal" y otra "oficial".

Ahora mismo tengo varias versiones de algunos canales y no tengo problemas tanto como si se usa filterchannels "dinámico" como si no.
Si quiero tener un canal "perosonal" por que no me gusta el "oficial" por muy actualizado que esté por qué no lo voy a poder tener?

A este paso me veo, ya no creando canales al gusto, si no más bien addon al gusto

SeiTaN escribió:Si un canal no funciona y se sube una versión en el foro (y posteriormente en GitHub), esto va en "channels", cuando se suba a GitHub se actualizará ese canal.

Si solo se comprueba el SHA1, cuando actualices canales (segun la configuracion) el canal del github sobreescribira al del foro. Me repito, pero el foro es mas rapido q github.

SeiTaN escribió:Los canales personales o versiones de pruebas que hagamos nosotros iria en "channels/personal" que esto no se machacaría nunca, y siempre se mostrarían si existen con el mismo nombre que en la carpeta "channels"

Yo descartaria el tema de la doble carpeta de canales. Para los ususarios normales ya es un lio encontrar una carpeta, cuanto mas 2 carpetas. Ademas puede ser un lio el uso de la biblioteca de kodi. Por otra parte ya existe la posibilidad de añadir canales personales (aunq confieso q no me lo he mirado nunca).

divadr escribió:He estado pensando yo... y si en lugar de comprobar el sha1 y luego la version del canal... comprobamos el sha1 del json? Si ha cambiado el json es porque ha cambiado la version no? De este modo al calcular el sha1 de un archivo mas pequeño tardara menos y ya nos serviria, No?

Si te refieres al sistema doble: SHA1 + version en json, si lo mismo nos da el py q el json y supongo q sera mas rapido este ultimo.

Mi propuesta de channelselector dinamico se basa en un archivo de indice de los canales q tenemos instalados q se crea al inicio si no existe y se modifica al añadir, actualizar o eliminar un canal. Tambien podriamos incluir ahi el SHA1 y la version del canal.json y asi no haria falta recalcularlo cada vez. ¿q os parece?

robalo escribió:El tema de eliminar archivos locales (canales) por decisión de terceros no me gusta nada.

En mi propuesta la ultima palabra la tienes tu. Es configurable desde el menu de opciones: ocultarlo, mostrarlo o borrarlo.