acc Geplaatst: 6 februari 2009 Geplaatst: 6 februari 2009 wat denk je ervan ook op "opensvn.csie.org" de code neer te zetten? ik denk dat je daar ook de meeste bijval mee ga krijgen. en kunnen de 2 projecten ook mooi synchroon lopen van bugs?
Sis Geplaatst: 6 februari 2009 Geplaatst: 6 februari 2009 Origineel bericht van: clark-kent Dit probleem speelt inderdaad nog steeds. Die issue was gemeld bij het voorgaande project, maar daar nooit opgepakt. Ik heb het ook al eens voorgelegd bij de ontwikkelaars van open-sasc-ng, maar die hebben er ook nooit op gereageerd. Het lijkt erop dat het gros van de ontwikkelactiviteit voor open-sasc-ng naar Nagra decoding gaat. Een enkele keer worden er algemene verbeteringen doorgevoerd (bijv NIT scanner). Ik heb gisteren eens een testje gedaan. Twee programma's opgenomen op SBS6 en Veronica. Om 17.10 en om 19.10. Alles is mooi opgenomen. Wil dit dan zeggen dat er slechts een sporadisch probleem is? ET9000: CCCam 2.3.0 - 13E, 19.2E, 23E, 28E DM800SE: CCCam 2.3.0 - 13E, 19.2E, 23E, 28E RaspberryPi OSCAM 120 r0
clark-kent Geplaatst: 6 februari 2009 Geplaatst: 6 februari 2009 Kan dan een sporadisch probleem zijn, of Canal Digitaal heeft iets veranderd waarmee het probleem zich niet meer voordoet! Dat laatste zou alleen maar beter zijn. Toen ik er tegenaan liep was het consequent. Vanaf welke tijd het probleem optrad leek dan te varieren van 16.30 - 17.30 uur, maar "primetime" opnames op die transponder faalden altijd. Sindsdien altijd trouw de patch toegepast. Ik zou zeggen, kijk het maar eens aan. De meldingen in de log zijn duidelijk genoeg om bij mislukte tune poging vast te stellen dat dit specifieke probleem de oorzaak is. Benieuwd of het nog optreed. Anders laat ik de patch ook achterwege.
Exposure Geplaatst: 20 februari 2009 Geplaatst: 20 februari 2009 Ik ben ook een beetje aan het spelen met een HTPC. Ik maak gebruik van een Mystique CaBiX-C2 (DVB-C) PCI kaart en een Smargo, op het Ziggo netwerk. Op zich werkt MythTV met open-sasc-ng best aardig, maar ik vind de zaptijden veel te lang. Het duurt tussen de 5 en 10 seconden voor ik beeld heb. Voor VDR is er een softcam plugin waardoor open-sasc-ng en de dvbloopback device niet nodig zijn. Zappen in VDR gaat veel sneller. Ik twijfel er eigenlijk een beetje of open-sacn-ng en de dvbloopback device verantwoordelijk zijn voor de vertraging, op het moment denk ik de het nog wel eens aan MythTV zelf kan liggen. Hoe zijn jullie zaptijden? Als ik kan natrekken waar de (meeste) vertraging vandaan komt kan ik wellicht hier en daar wat code tweaken. Overigens ben ik een patch tegengekomen die de sc functionaliteit intern toevoegt aan mythtv, dvbloopback+sasc-ng zijn dan dus overbodig (MythTV doet het dan op een manier vergelijkbaar met VDR). Helaas is deze patch al oud en is het dus flink wat werk om hem te laten compilen met een recente MythTV. Voor ik die tijd er in ga steken wil ik er eerst graag achterkomen of sasc-ng / dvbloopback verantwoordelijk zijn voor de vertraging, of dat het in MythTV zelf zit.
Lamko Geplaatst: 20 februari 2009 Auteur Geplaatst: 20 februari 2009 Kan k heel kort in zijn, ligt aan Mythtv, duurt bij mij ook ongeveer een 5 sec. Komt omdat Mythtv de data eerst op de hd opslaat en dan het gaat afspelen. Zo is Mythtv gebouwt en volgens mij kun je dit ook niet vlug even aanpassen. Mythbuntu 12.04 Celeron 220 op Mini-ITX D201GLY2, 1 GB Ram,2x1,5 TB HDD, Digitenne op TerraTec Cinergy, CCcam
acc Geplaatst: 20 februari 2009 Geplaatst: 20 februari 2009 Bij mij gaat het redelijk snel, als ik dat zo hoor. ik heb binnen de 2sec zeker beeld op FTA. voor het gecodeerde-gedeelte kan ik niets zeggen. daar ben ik nog aan bezig om het werkend te krijgen. wat ik wel gemerkt heb, (maar dat vind ik zelf wat raar) is dat, als de stream via de gigabit switch gaat, dat ik sneller beeld heb dan via de 100Mbit switch, en dan heb ik het over "live" beeld. opgenomen programma's is nogal logisch. ik moet ook wel zeggen dat de snelheid bij mij, van het oproepen van "live"beeld sneller gaat met de DVB-kaartje die ik nu heb dan met de analoge tuners die ik had. ook draai ik nu op de backend Mythbuntu 8.10 X64.
Exposure Geplaatst: 20 februari 2009 Geplaatst: 20 februari 2009 Met welke hardware is dit? Ik ken het argument dat MythTV direct begint met opnemen en dat er enige vertraging is vanwege het openen van het mpeg bestand etc. Daar heb ik alle begrip voor, maar dat moet toch echt sneller kunnen dan 5 seconden. De vertraging bij mij zit 'm vooral in het tunen. Als dat eenmaal gelukt is duurt het nog een tijdje voordat mythtv beeld geeft vanwege het openen van de mpeg file en dergelijke, maar daar kan ik best mee leven.
acc Geplaatst: 20 februari 2009 Geplaatst: 20 februari 2009 hardware die ik gebruik: backend: - AMD 5000+ - 1GB ram - 2X 250GB hardware raid 0 - 1X DVB-C (satelco HD) 1X DVB-C technotrend c-1500 verschillende frondend's op deze gaat het goed: - T2400 / 1GB ram - T5600 /1GB ram - D945 / 1GB ram eigenlijk niets speciaal van hardware en draait toch wel vlot. maar ik ben van zin om te downgraden voor het energie verbruik naar beneden te brengen. en atom frontends te gebruiken die boten over netwerk.
acc Geplaatst: 22 februari 2009 Geplaatst: 22 februari 2009 is het mogelijk om die patch beschikbaar te maken? en wat zou er dan volgens jou moeten aangepast worden?
Exposure Geplaatst: 22 februari 2009 Geplaatst: 22 februari 2009 De patch waar ik het over had is hier te vinden. Het probleem is dat ie gemaakt is voor MythTV rev.14932 en we zitten op het moment op 20038. Ik kan zo niet zeggen wat er aangepast moet worden, er zijn grote delen van de patch die niet meer werken met de huidige source.
clark-kent Geplaatst: 23 maart 2009 Geplaatst: 23 maart 2009 Ruim een maand verder en gelukkig heb ik nu wel een stabiele setup kunnen krijgen. Alles wijst er tot nog toe op dat de bron van mijn problemen zat in het handmatig hernummeren van inputids en oude inputgroup entries in de database. Bij toeval kwam ik erachter dat in de mythconverg database allemaal entries waren in de tabel inputgroup. Voor zover ik na kan gaan worden die toegevoegd door mythtv-setup als multirec aangezet wordt. Met het handmatig hernummeren van inputids (om prioriteiten te corrigeren) heb ik niet de inputgroup tabel bijgewerkt (tot voor kort wist ik niet eens van het bestaan af). Daarmee conflicteerden sommige referenties wat zo nu en dan dus blijkbaar tot een volledige crash leidt. Omdat ik vermoedde dat er problemen waren met multirec icm open-sasc-ng draaide ik al een poos zonder multirec (nog steeds). Daarmee kon ik veilig die conflicten herstellen door de inputgroup tabel leeg te gooien (na het maken van een backup). Nu ik een stabiele setup heb (welke ook netjes kaartupdates ontvangen heeft) blijf ik er eerst even vanaf. De stabiele setup heeft ook nog geen opname gemist of 0byte opnames gegeven! Canal Digitaal is nog volop aan het omruilen van de abo-kaarten, dus tot die tijd laat ik het eerst even zo. De eerste successen met de nieuwe Seca3 kaarten zijn al gemeld, dus hopelijk blijft alles stabiel. Over een paar maanden zet ik multirec wel weer eens aan.
acc Geplaatst: 27 maart 2009 Geplaatst: 27 maart 2009 Origineel bericht van: clark-kent Ruim een maand verder en gelukkig heb ik nu wel een stabiele setup kunnen krijgen. Alles wijst er tot nog toe op dat de bron van mijn problemen zat in het handmatig hernummeren van inputids en oude inputgroup entries in de database. Bij toeval kwam ik erachter dat in de mythconverg database allemaal entries waren in de tabel inputgroup. Voor zover ik na kan gaan worden die toegevoegd door mythtv-setup als multirec aangezet wordt. Met het handmatig hernummeren van inputids (om prioriteiten te corrigeren) heb ik niet de inputgroup tabel bijgewerkt (tot voor kort wist ik niet eens van het bestaan af). Daarmee conflicteerden sommige referenties wat zo nu en dan dus blijkbaar tot een volledige crash leidt. Omdat ik vermoedde dat er problemen waren met multirec icm open-sasc-ng draaide ik al een poos zonder multirec (nog steeds). Daarmee kon ik veilig die conflicten herstellen door de inputgroup tabel leeg te gooien (na het maken van een backup). Nu ik een stabiele setup heb (welke ook netjes kaartupdates ontvangen heeft) blijf ik er eerst even vanaf. De stabiele setup heeft ook nog geen opname gemist of 0byte opnames gegeven! Canal Digitaal is nog volop aan het omruilen van de abo-kaarten, dus tot die tijd laat ik het eerst even zo. De eerste successen met de nieuwe Seca3 kaarten zijn al gemeld, dus hopelijk blijft alles stabiel. Over een paar maanden zet ik multirec wel weer eens aan. heb je hier een handleiding voor? want ik ga volgende week ook beginnen met de DVB-S setup.
clark-kent Geplaatst: 29 maart 2009 Geplaatst: 29 maart 2009 Ik heb nooit de moeite genomen alles eens op te schrijven. Mijn huidige setup is CentOS 5 x86 met centosplus kernel, twee Hauppauge Nova-S tuners, NewCS 1.65, open-sasc-ng r54 en atrpms.net mythtv packages 0.21-fixes build 203 (backend only configuratie). Mijn diskless frontends draaien MiniMyth. Voor open-sasc-ng heb ik twee patches toegepast. Een van die patches is toegevoegd sinds r62 en die andere wordt hier beschreven, maar schijnt niet meer nodig te zijn. Mocht je specifieke vragen hebben, stel ze gerust en ik zal mijn best doen ze te beantwoorden. Succes met jouw setup.
acc Geplaatst: 29 maart 2009 Geplaatst: 29 maart 2009 zou je eens meer uitleg kunnen geven over die inputids? wat heb je er juist aan veranderd? en is het standaard anders ingesteld? zo ja, wat moet er dan juist veranderd worden. je ziet, vragen genoeg
clark-kent Geplaatst: 30 maart 2009 Geplaatst: 30 maart 2009 Als het goed is hoef je hier nooit iets mee te doen. Met het definieren van de tuners in mythtv-setup krijgen de inputs een eigen inputid. De keuzes die mythtv-setup daarin maakt zijn op zich prima en kun je mooi laten voor wat het is. In mijn geval wilde ik de volgorde van de inputids aanpassen (zodat een andere fysieke tuner met disecq switch en twee LNBs een voorkeur keuze werd bij LiveTV - die kiest namelijk de laagste inputid). Dit kon ik doen door de inputs te verwijderen en opnieuw aan te maken in de gewenste volgorde. Eigenwijs als ik ben heb ik het meteen in de MySQL tabellen aangepast wat als gevolg had dat ik een detail (inputgroups) over het hoofd zag. Direct aanpassen van MySQL tabellen is dus niet zonder risicos omdat er allerhande referenties naar andere tabellen kunnen zijn die dan ook veranderd moeten worden. De wijziging die ik dus deed was een specifiek geval wat ik ook met de standaard tools had kunnen bereiken.
Aanbevolen berichten
Maak een account aan of log in om te reageren
Je moet een lid zijn om een reactie te kunnen achterlaten
Account aanmaken
Registreer voor een nieuwe account in onze community. Het is erg gemakkelijk!
Registreer een nieuwe accountInloggen
Heb je reeds een account? Log hier in.
Nu inloggen