MythTV-fr

Bonjour Gilles,
Les infos que j'ai:
1- arrêt des chaines SD au mois de juin 2015, toutes les chaines basculent en HD ou en SD transmit en HD ( bonjour l'arnaque)
2- arrêt de la vente des cartes seules (39) a l'été 2015, quid de tout le matériel certifié canal ready ! il faut impérativement loué le décodeur canal ( c'est une vente forcée si la personne possède un décodeur canal ready ).

A ce jour , je ne sais pas encore vers quoi je vais me tourner, mais une chose est sure c'est que canal nous la mit bien profond. C'est la que je ne comprend pas la position du CSA qui depuis des années protège  le groupe canal avec des pratiques commerciales douteuses et des rachat de concurrents (TPS,....) pour avoir le monopole. Maintenant on en voyons le résultat final.

Encore une fois merci a nos élites/énarques, tous des pourris.

Je viens de tester le patch automatique du kernel 3.2 ubuntu 12.04, le module dvbloopback fonctionne correctement

Sep 12 19:17:15 fabrice-Vostro-1720 kernel: [ 1126.596348] /home/fabrice/workspace/ffdecsawrapperFMG/dvbloopback/module/dvb_loopback.c: frontend loopback driver v0.0.1
Sep 12 19:17:15 fabrice-Vostro-1720 kernel: [ 1126.596352] dvbloopback: registering 2 adapters
Sep 12 19:17:15 fabrice-Vostro-1720 kernel: [ 1126.597857] DVB: registering new adapter (DVB-LOOPBACK)
Sep 12 19:17:15 fabrice-Vostro-1720 kernel: [ 1126.603347] DVB: registering new adapter (DVB-LOOPBACK)

Great job bas-t !:lol:

What is the configuration you use?

satellite astra
|
FFdecsawrapper -> protocol newcamd -> oscam(rev 8340) -> card
|
mythtv

Non, cette version ne décode pas la HD, pas plus que les autres pour le moment. Mais plein de personnes essaient de résoudre ce problème.

tres bon choix pour la gt220 , c'est ce que j'ai depuis environ 2 ans

Bonjour
Apres des années de tests en tous genres et surtout en qualite d'image sur le frontend, le choix dans l'ordre c'est:

1 Nvidia
2 Intel
3 Amd

De mémoire, il y a un port de debug qui s'ouvre , "Listening on port 5456"

Justement, il faut mettre desc_episode=1, mais ce n'est pas pour cela que dans le frontend les épisodes seront classés. Il faut impérativement mon script pour les transférés dans la base sinon pas de classement dans le frontend ( a part si c'est enregistré dans l'ordre ). Les explications vaseuses sur le chat mythtv ne sont pas convaincantes a priori a cause Schedules Direct pour les US.
Enfin, il est totalement anormale que les 'Prochaints enregistrements' qui ont l'information dans le champ 'syndicatedepisodenumber' soit perdu quand ils passent dans 'Programmes enregistrés'.
Il y a une autre solution mais beaucoup plus incertaine , c'est de remplir manuellement les infos dans le frontend depuis la 0.26 ou de mythweb mais c'est long!

bon courage

PS: il faut mettre dans le frontend 0.26, configuration->réglage TV->lecture : Trie des épisodes : Saison/Épisode

Salut gilles,

cela fonctionne parfaitement depuis le la version 0.24 pour les programmes qui VONT être enregistrés.

Il trouve parfaitement les nouveaux des anciens
La basile <episode-num system="xmltv_ns">3.11/12.</episode-num>, mythtv le comprend tres bien pour les futures enregistrements

Ce que ne fait pas mythtv, et c'est très dommage je ne pense pas que ce soit le plus compliquer, c'est que lors de du passage de status "future" a "enregistré" (table program-> recorded ) il ne copie pas les informations ou ne les utilise pas !

La combine pour les avoirs c'est de contourner le problème en copiant l'info "Saison 04 Episode 12/12" dans le descriptif et de lancer un script a la fin de l'enregistrement pour compléter la table "recorded"

voici mon script que j'execute a la fin de chaque enregistrement , c'est le backend qui le lance ( voir le gestionnaire d'evenement )

#!/usr/bin/env python2
# -*- coding: utf-8 -*-
'''
Created on 6 août 2011

@author: fabrice
'''

import os
import re
from MythTV import MythDB


#===============================================================================
# main 
#===============================================================================
if __name__ == '__main__':
     
     DB = MythDB()
     
     try:
        request = 'SELECT * FROM recorded'
#        list_record = []
        c = DB.cursor()
        c.execute(request)
        for row in c.fetchall():
            episode = 0
            season = 0
            description = row[5]
            tmp = None
            # episode
            tmp = re.search(r'Episode (?P<episode>\d\d)', description, re.MULTILINE | re.UNICODE)
            if tmp != None:
                if tmp.group != None:
                    episode = int(tmp.group('episode'))
                    if episode <> row[7]:
                        request = 'UPDATE `recorded` SET `episode` = %s WHERE `chanid` = "%s" and `starttime` = "%s"' % (episode, row[0], row[1])
                        c.execute(request)
            # season
            tmp = None
            tmp = re.search(r'Saison (?P<season>\d\d)', description, re.MULTILINE | re.UNICODE)
            if tmp != None:
                if tmp.group != None:
                    season = int(tmp.group('season'))
                    if season <> row[6]:
                        request = 'UPDATE `recorded` SET `season` = %s WHERE `chanid` = "%s" and `starttime` = "%s"' % (season, row[0], row[1])
                        c.execute(request)
     finally:
        c.close()

J'ai basculé ce WE et tout c'est bien passé
Pour une fois j'ai rien touché !
Par contre, j'ai vu des problèmes passés sur la ML avec gentoo