Beiträge von löwe

    Noch 2 Probleme, das mir schön öfters aufgefallen ist:


    * Hohe CPU-Auslastung ohne merklichen Grund
    Ich hab innerhalb von xbmc öfters hohe CPU-Auslastung (100 % oder mehr), ohne dass die Anwendung dem Anschein nach etwas tut (kein EPG-Update, keine Infos auf der Oberfläche ersichtlich, und das Logfile deutet nur auf einen Leerlauf hin)


    Zwar weiß ich nicht, ob das konkret mit der PVR-Erweiterung etwas zu tun hat, auffällig ist es jedenfalls.



    * Regelmäßig Lags bei HDTV-Wiedergabe mit VDPAU
    Normalerweise sieht es bei der Wiedergabe von HD-Sendern so aus (lt. Infos von xbmc):


    Interlaced-Sender (wie ServusTV HD, Anixe HD): 25 fps
    Progressive-Sender (wie Das Erste HD, arte HD): 50 fps


    Gelegentlich wird mir bei diesen Sendern eine andere (wohl falsche Framerate) angezeigt, die ca. um die 32 fps herum zu schwanken zu scheint.


    Ich nehme an, dass in so einem Fall die Wiedergabekomponente Probleme bei der richtigen Erkennung des vorliegenden Formats (Halbbilder, Vollbilder) hat und es deshalb zu diesen Problemen kommt.


    Im Bild macht sich dies so bemerkbar, dass dieses im Abstand von ca. einer halben Sekunde regelmäßig für einen kurzen Moment stecken bleibt und dann im Anschluss gleich wieder schnell weiterläuft. Diese beiden Zustände wechseln stetig in gleichbleibenden Zeitabständen ab. Ich nehme dabei an (ohne es zu wissen), dass der Moment in dem das Bild scheinbar flüssig abläuft, zu schnell wiedergegeben wird.


    Bei einer jeden "Pause", in denen das Bild "wartet", erhöht sich der Zähler der gedroppten Frames um einige Frames.


    Ob das Problem etwas mit VDPAU zu tun hat, weiß ich ehrlich gesagt nicht.

    Auf meine Bestellung hin (ich war so forsch und hab gleich um 2 Brillen gebeten :D ) hab ich nicht einmal so ein Mail wie deines erhalten, sonder gar keine Rückmeldung.


    Bestellt habe ich irgendwann im Jänner. Nach geschätzt 3 Wochen war dann ein Briefkuvert mit den Brillen da :D


    Ich denke die Brillen werden schon kommen, auch wenns nach einer Bestellung vielleicht länger dauert

    Hallo pingpong!


    Mit den letzten paar Updates läuft xbmc so weit echt super und die größten Dinge wie Freezes wenn innerhalb von Xbmc etwas nicht klappt sind damit wohl soweit beseitigt :)


    Gestern sind mir beim Test der PVR-Funktionen noch die folgenden Punkte aufgefallen:


    * Das Erste HD und ZDF HD
    Beim Abspielen dieser Sender wechselte xbmc beim Schalten auf den Vollbildmodus auf 60 Hz Betrieb (anstatt bei 50 zu bleiben wie das Bildmaterial wohl vorliegen dürfte)


    Nach der Umschaltung auf 60 Hz habe ich konstant im Abstand von geschätzt einer halben Sekunde Ruckler/Lags in der Darstellung.


    Bei Anzeige der Infos zum wiedergegebenen Stream wird mir dabei fortan eine Framerate von ca. 53 fps angezeigt. Der Wert jedoch variiert leicht um die 53 (Nachkommastellen)


    Verlasse ich den Vollbildmodus wird die Bildwiederholrate richtigerweise wieder auf 50 Hz umgestellt. Das Fernsehbild im Fenster weist dann jedoch die selben Ruckler wie im Vollbildmodus auf.


    Besonderheit: Unmittelbar nach dem Einschalten des Kanals (also *vor* Wechsel auf den Vollbildmodus) wird das Bild im Fenster ruckelfrei wiedergegeben.


    Tritt auf wie gesagt nur bei ZDF HD und Das Erste HD.


    Logs kann ich wenn gewünscht gerne bereitstellen.



    * Allgemeine Probleme Kanalwiedergabe
    Beim Start der Wiedergabe von Kanälen mit schlechterem Empfang wird der Vorgang nicht immer erfolgreich durchgeführt --> nach einigen Sekunden wird mit einer Fehlermeldung abgebrochen.


    Bei unmittelbar darauffolgenden, neuerlichem Start der Wiedergabe des selben Kanals wird dieser dann zumeist innerlab des Bruchteils einer Sekunde wiedergegeben.


    Zum 1. fehlerhaften Wiedergabe-Versuch:
    Das Problem / der Abbruch tritt auf, obwohl das Backend (in meinem Fall VDR / streamdev) bereits einen Datenstream zu xbmc sendet.


    Gleich nach Abschluss des Tuning-Vorgangs der TV-Karte bzw. zu Beginn des Streamings scheinen diese Daten jedoch meiner Meinung nach unsauber / fehlerhaft zu sein, womit der Wiedergabe-Teil von xbmc nicht immer ganz so gut zurecht kommen dürfte.


    Ich weiß - xbmc wurde für nicht-fehlerbehaftete Daten-Streams mit Fehlerkorrektur geschaffen (wie solche von Datenträgern/Netzwerk kommend) und ist deshalb wohl darauf ausgelegt.


    Vielleicht könnte man ja künftig Optimierungen für nicht-fehlerkorrigierte Broadcast-Streams vornehmen, so wie dies bei SAT-Receivern ja auch der Fall ist ...


    Das Problem ist aber nicht sonderlich schlimm, Logs kann ich auch hierfür gerne bereitstellen.



    * H264-codierte Übertragungen / Kanäle werden gelegentlich nicht mittels VDPAU, sondern via Software wiedergegeben.


    In aktueller Version von xbmc tritt dies zwar nicht mehr ganz so oft auf wie früher, es kann aber trotzdem immer wieder mal passieren, dass auf Software-Decoding zurückgegriffen wird.


    Lt. Infos von anderer Stelle dürfte dies damit zusammenhängen, dass in so einem Fall der von xbmc verwendete Demuxer das exakte Videoformat / die Auflösung nicht erkennen kann, zur Initialisierung von VDPAU diese vom Demuxer kommenden Informationen aber zwingend benötigt werden.


    Eventuell hängt dies ja auch mit schlechter Datenqualität zu Beginn einer Übetragung zusammen (siehe vorherigen Punkt)



    * Freeze bei ORF1 HD und ORF2 HD
    Bei Wiedergabe dieser Kanäle friert das Bild nach ca. 1-2 Sekunden bei mir konstant ein - Beginnend mit Wegfall des Tons, gleich danach gefolgt vom Freeze des Bildes.


    So weit ich das bis jetzt eruieren konnte, dürfte das Problem nur bei mir auftreten (besser gesagt tritt es bei anderen nicht auf), weshalb diese spezielle Sache insegsamt wohl sehr blöd sein dürfte ...


    Ergänzung: Die ORF HD Freezes betreffen nicht xbmc selbst, sondern nur die aktuelle Wiedergabe des TV-Kanals. Mittels Stopp-Taste kann die eingefrorene Wiedergabe problemlos abgebrochen werden.


    In den Logs habe zu diesem Problem leider nur Hinweise darauf gefunden, dass vor dem Freeze das Audio-Signal nicht völlig synchron vorzuliegen scheint - und selbst das scheint leider von Freeze zu Freeze leicht zu variieren.

    Hallo!


    Ich hab mir ein JCP MI 103 Gehäuse mitsamt POV ION 330-1 Mini-ITX Mainboard gekauft.


    Gehäuse


    Im Gehäuse nutze ich eine Riser-Karte und hab insgesamt eine TV-Karte sowie ein CI-Modul in den 2 Slots stecken.


    Leider musste ich feststellen, dass meine 3,5 Zoll Festplatte um ca. einen halben Zentimeter zu weit nach hinten steht und an den 2 Steckkarte bzw. an der Riser-Karte ansteht.


    Ich bin daher quasi gezwungen eine 2,5" Notebookfestplatte zu kaufen, und dazu nun meine Frage:


    Habt ihr eine solche im Einsatz, mit der ihr sehr zufrieden seid?


    Meine Anforderungen:
    * SATA
    * ca. 500 GB Speicher
    * leise
    * wenn möglich geringer Stromverbrauch

    Zitat

    Originally posted by hotzenplotz5
    eigentlich machst du doch alles richtig?
    ich glaube malloc schliesst einfach gerne tickets......
    machs doch einfach wieder auf :D
    und frag nach wie du sonst einen bug melden sollst ?!
    aber ich denke da sollte pingpong mal intern was mit malloc regeln.


    Wenn ich den Bug nur wieder aufmachen könnte/dürfte.


    Kommentiert habe ich ihn schon, nur den Status müsste jemand anderer ändern, mit den notwendigen Rechten dazu ...


    Aus einem anderen Bug - mit dem selben Kommentar von malloc - denke ich nun zu wissen, was hier wirklich passiert.


    Malloc scheint zu glauben, Bugs die einen Branch betreffen (wie hier ja den pvr-testing2 branch) habem im Trac generell nichts verloren.


    Siehe hier: http://www.xbmc.org/trac/ticket/8623


    Dort schreibt er, man solle bei solchen Bugs warten, bis der Branch im Trunc landet, und ihn dann später als Trunc-Bug einmelden, da hierfür Trac ja da ist ....


    Dass die PVR-Component allerdings für genau nur den Branch eingerichtet wurde, und deshalb ausschließlich nur solche Bugs dort eingetragen werden, die den Branch betreffen - also Trunc-Bugs dort gar nie landen können - das scheint sich zu malloc noch nicht herum gesprochen zu haben.


    Er scheint also nur nicht zu wissen es besser machen zu können ...

    Was dein Aufhängen betrifft, könnte das dieser Bug hier sein.


    Wie Bugs einmelden?


    Leider sieht es düster aus, was dessen Bearbeitung durch jemanden betrifft, da er von jemanden unvollendet geschlossen wurde, und geschlossene Bugs sieht sich natürlich keiner an, ist ja klar.


    Das 2-malige Anwählen eines Sender, bis dann VDPAU genutzt wird, könnte damit zu tun haben:


    VDPAU wird sporadisch nicht genutzt bei HD-TV via Streamdev-Schnittstelle


    Da gibt es eine Aussicht, dass es irgendwann behoben wird, das Problem.

    So weit ich das verstehe dürfte das zum Glück nicht der Fall sein :D


    Aus dem Kommentar:


    dzt. Ablauf:
    1. Schicken des Video-Streams durch den Demuxer
    2. Demuxer ermittelt Dimensionen
    3. VDPAU wird mit den Demensionen aus dem Demuxer initislisiert


    Das Problem ist nun, dass der Demuxer statt den Dimensionen manchmal gar nichts liefert (ist mit 0x0 beschrieben im Kommentar) --> VDPAU stürzt deshalb beim Initialisieren ab --> Xbmc führt ein Fallback auf Software-Rendering aus, was ja bekanntlicherweise immer klappen sollte


    Was im Kommentar vorgeschlagen wird, ist Folgendes:
    1. Statt VDPAU Starten des Software-Renderers für den Video-Stream
    2. Gleich zu Beginn ein Abwürgen des Software-Renderers, dafür aber von ihm die Dimensionen auslesen (der SW-Renderer erkennt die Dimensionen ja richtig, sonst könnte er diese Videostreams nicht wiedergeben, und er kann sie ja offensichtlich abspielen)
    3. Mit den vom SW-Renderer ausgelesenen Dimensionen die Initialisierung von VDPAU durchführen
    4. Den Stream mit VDPAU abspielen.



    Ich würde, nachdem im Bug-Kommentar von spiff ja alles Notwendige schön aufgeschlüsselt ist, noch weiter gehen:


    1. Schicken des Video-Streams durch den Demuxer
    2. Demuxer ermittelt Dimensionen
    3. Wenn die Dimesionen des Demuxers 0x0 sind, dann Start des SW-Renderes, gleich später Abwürgen dessen und die Dimeinsionen darauf merken
    4. Initialisierung von VDPAU mit den zuvor gewonnenen Dimensionen (unabhängig woher diese stammen --> Demuxer oder SW-Renderer)
    5. Wiedergabe des Streams mit VDPAU



    Ein Bugfix ist schon möglich, und mit meiner 5er-Grupper hier dürfte sich die Performance damit auch nur dann verschlechtern, wenn VDPAU jetzt versagt; bei der normalen Wiedergabe sollte damit alles gleich bleiben, da dafür auf den SW-Decoder verzichtet wird. Ist ja auch nicht notwendig, denn solche Streams funktionieren jetzt ja auch schon ohne ihn.

    Meine GeForce 9400 GT (passiv gekült, und leider der Steckplatz darunter und darüber verbaut in einem Media-Center-Gehäuse) erreichte 113 Grad. Dazu habe ich auch mal einen Thread eröffnet.


    Durch das Hinstellen eines 8 cm Lüfters im Gehäuse, der nun Luft von hinten zwischen die Karten in Richtung Slotblenden des Gehäuses drückt liegt die Temperatur nunmehr bei rund 60 Grad (+/- ca. 3 Grad je nach Nutzung, zB SD oder HD)


    Spezifiziert ist sie lt. meinen Infos für eine Maximaltemperatur von 105 Grad. Bemerken konnte ich eine effektive Drosselung der Geschwindigkeit bei 110 Grad (H.264 mit VDPAU ruckelten ab dieser Temperatur)


    Mit den 60 Grad die ich nun habe, bin ich recht zufrieden, denn bei höheren Temperaturen (um die 100 Grad) würde ich mir Sorgen um die umliegenden Steckkarten machen (zB die TV-Karte) - auch wenn die Grafikkarte selbst lt. Hersteller mit 100 Grad zurecht kommen dürfte.

    Zitat

    Original von gda
    Was soll denn der Mist? Warum bohrst du ständig nach? Der Build-Prozess steht doch für Jeden zugänglich in den Paket-Sourcen.


    Na gut, frei nach dem Motto "Der Code ist die beste Dokumentation" werde ich mir das Endprodukt daraus ziehen. Ist ja zum Glück ein GPL-Paket.


    Werde mich hier wohl dieses Thema betreffend zurück halten und ggf. einen neuen Thread eröffnen, da hier offenbar nicht erwünscht, und Resonanz scheints auch nicht zu geben.


    Ich frage mich aber schon, wie bei einer solchen Einstellung überhaupt größere Projekte zustande kommen können. Als ob ihr grundsätzlich nichts davon halten würdet die Akzeptanz von Xbmc bei den normalen Benutzern zu erhöhen ... aber von mir aus soll es so sein ...

    Zitat

    In diesem Thread geht es um die Ubuntu-Pakete, die ich baue, und wie gut sie funktionieren.


    Betrachte den Satzteil nach dem letzten Beistrich, und du hast genau den Grund, der mich überhaupt erst auf all meine Gedanken zum Thema brachte.


    Ehrlich gesagt habe ich ja auf eine solide Basis von dir gehofft, was die derzeitigen Erfahrungen zum Builden betrifft.


    Wie machst du es denn derzeit? Was ist besonders heikel dabei, oder läuft sowieso alles nur straigth forward?


    Denn wozu das Rad neu erfinden und erstmal einen funktionierenden Ubuntu-Build-Prozess neu erstellen, wenn man sich auch gleich der Automatisierung des Bestehenden - gut Funktionierenden - widmen könnte.



    Was ist denn deiner Meinung nach das Optimum? Ist dein geschaffener Prozess ein Ideal? Kocht jeder in der Open-Source-Gemeinde nur sein eigenes Süppchen?


    Ich weiß vieles diese nicht-technischen Hintergründe betreffend nicht. Nur so viel, dass es sich wohl nicht um die beste Ausganssituation handelt.



    Solltest du es übrigens notwendig haben, auf konkrete Fragen hin auf Sarkasmus und Polemik auszuweichen, so bin ich der Letzte, der dich daran hindern wird.


    --edit:
    Um nicht vom Thema (deine spezifischen Pakete für Ubuntu und wie sie funktionieren; siehe dein vorheriges Posting) abzuweichen:


    Wie buildest du denn ein Paket (wie funktioniert es bei dir)? Verwendest du die Debian/Ubuntu-Scripte die sich im SVN-Repository befinden und offenbar 1:1 vom trunk übernommen wurden, oder sind spezielle Modifikationen bzw. gar eine neue Umgebung notwendig?

    Um die Übersicht nicht ganz zu formulieren, hier nochmals mein eigentliches Grundanliegen, bei wem auch immer es Gehör finden möge:


    Hier wurde ja erwähnt, Daily-Builds hätten nur einen Sinn wenn Entwickler sie nutzen würden. Ich glaube zu bemerken, dass auch weiter auseinanderliegend erstellte Pakete nicht wirklich brauchbarer sind für den "Normalbenutzer".


    Mit den letzten 3 Hepi-Builds (danke übrigens für die Arbeit :D) hat jeweils irgend etwas nicht funktioniert, das vorher schon lief - und nunmehr mehr oder weniger störend auffiel - oder meine Installation wurde komplett zerschossen.


    Ich bin dafür, die Qualität des pvr-testing2 Branches zu steigern, und zwar indem die darin aufwändigst geleistete Arbeit für den normalen Benutzer einfach formuliert benutzbarer wird.


    Darin würde ich Vorteile sehen, was die Verbreitung der Installationen von Xbmc mit den PVR-Funktionen betrifft, eine Verfestigung von Xbmc-PVR unter den Nutzern, und nicht zuletzt sollte all dies nicht zum Nachteil sein, wenn es um eine eventuelle Aufnahme der PVR-Funktionen in den trunk geht.


    Umsetzen würde ich das durch folgende Maßnahmen (technischer Natur):


    * Zeitnahe Übernahme der aktuellen Entwicklungen in über die Paketverwaltung installierbare Pakete (zB taggleich nach SVN-Commits)
    * Anbieten zumindest einer Vorversion im Repository, sodass man den Usern nach einem aptitude upgrade auf eine kaputte Version ein einfaches Downgrade mittels aptitude downgrade (downgrade steht hier nur sinngemäß für den tatsächlichen Befehl) ermöglicht.



    Natürlich bedeutet dies einen Mehraufwand im Vergleich zum jetzigen Prozess - wer auch immer diesen Aufwand mit seiner Zeit und seinem Wissen bewältigt.
    Diesen Aufwand würde ich versuchen mittels Automatisierung zu kompensieren, bzw. wäre es ein Nice-To-Have den Aufwand im Vergleich zum derzeitigen System sogar zu reduzieren.


    Vorstellen könnte ich mir, dass die ohne Zutun am Script-Server ablaufende Paketerstellung im Fehlerfall per Mail benachrichtigt, und der Paketbauer so nur im Fehlerfall Hand anlegen muss.



    So weit mein Vorschlag. Eventuell kann man daraus ja etwas schaffen.

    Zitat

    Original von hepiDeinen Beitrag finde ich eine Frechheit, deshalb werde ich Deine Fragen nicht mehr beantworten.


    Für mich ist ein Forum ja dazu da, um vor allem sachliche - und speziell hier technische - Diskussionen zu führen.


    Leider sehe ich, dass mit dir zu bestimmten Themen eine solche leider nicht möglich ist.


    Während ich den Sinn in einem Open-Source-Projekt im gemeinsamen Vorantreiben der Arbeiten und Tätigkeiten in Richtung des Erfolgs sehe (man möge mich korrigieren), scheinen dir speziell hier nun persönliche Befindlichkeiten wichtiger zu sein.


    Es ist wirklich schade, aber auch gut nachzuvollziehen: Nachdem ich mir hier prinzipiell eine richtungsweisende Antwort auf eine Frage erwartet habe, und gleichzeitig Mitarbeit/Zeit + Server-Ressourcen angeboten habe, wurde das von dir pauschal mit bestechend einleuchtenden Darstellungen wie "30 % von dem was du sagst stimmt nicht" abgewürgt.


    Ich würde in diesem Fall es ja so sehen: 60 % würden deiner Beschreibung nach eben genau schon stimmen, und das Ziel anstrebend, das Projekt voranzutreiben würde ich die 30 % eventuell richtig stellen.


    Mir würde es nie einfallen aufgrund einer technisch fundierten eingebrachten Diskussion jemandes Fragen nicht mehr zu beantworten, noch würde ich nicht mit Worten wie "Frechheit" daraufhin um mich herum werfen.


    Wären es tatsächlich alleinig technische Umstände, welche ein solches Vorhaben verunmöglichen, so würde sich doch anbieten genau dies anzumerken. Man muss doch deswegen nicht den gekränkten Helden spielen, der mit allem anderen als sachlichem Hintergrund antwortet ...


    Ich trete ja immer dafür ein, die Dinge wie sie sind auf den Tisch zu legen. Mir war von Anfang an klar, dass ich mit meinem Vorschlag des Automatisierens von Builds den vorhandenen Prozess grundsätzlich in Frage stelle und bei einer Umsetzung den jetztigen Personen dahinter die Kompetenz dafür - zumindest zum Teil - genommen wird.


    Ist es wirklich so ein großes persönliches Anliegen kann man das ja auch bedenkenlos sagen (zB "Ich habe das geschaffen. Ich mache es. Ich werde es auch zukünftig so machen, da mir ... die Anerkennung dahinter ... enorm wichtig ist und bin deshalb gegen eine Veränderung / auch wenn es eine Verbesserung wäre)


    Ist ja nichts dabei. Wenn es nach mir geht, sind derartige Umstände - neben den rein technischen - genauso zu beachten bzw. ist ihnen ein Stellenwert zuzuschreiben.



    Geht es nach mir, steht es im Übrigen völlig außer Zweifel, dass hepi hier wichtige Arbeit macht und zu Xbmc/PVR ganz wesentlich beiträgt.


    Ohne seine viele Zeit und Motivation die er aufbringt, wäre das von uns allen genutzte Media-Center wohl bei weitem nicht dort, so es uns heute alle schon großartige Dienste erweist.



    Zitat von "hepi"

    Man kann durch IT alles automatisieren, aber man muss auch entscheiden, ob es sinnvoll ist, alles zu automatisieren.


    Automatisierung macht nur dann Sinn, wenn dadurch sonst laufende Arbeitsaufwand verringert wird.


    Da du ja selbst hier schon mehrmals beschrieben hast wie umfangreich und hoch komplex diese Tätigkeiten sind, deutest du eigentlich nur selbst darauf hin, dass dahingehende Überlegungen nicht ganz abwegig sind.


    Wird durch eine Automatisierung der laufende Aufwand hingegen nicht geringer, bzw. sogar größer, ist an der Sache grundsätzlich etwas schief gelaufen, und man sollte das Konzept an sich wohl besser nochmals überdenken.



    Zitat von "hepi"

    der einzige für den ich nightly builds machen würde, wäre pingpong. Weil nightly-builds für Entwickler sind. Wenn pingpong mich fragen würde, würde ich mit ihm darüber diskutieren.


    Das muss ich noch einwerfen ... bitte nicht als Stichelei verstehen, das ist es nämlich nicht.


    Wenn er es sagt, dann ist es natürlich sofort etwas, das sinnvol sein könnte und damit zu diskutieren ist.


    Selber Vorschlag von anderen (konkret: mir - siehe oben) hingegen ist offenbar generell abzulehen.


    Mir fällt dazu nichts anderes ein, als dass hier Einige offenbar glauben, untergeordneter Teil einer Hierarchie zu sein, die man selbst im kommerzilellen Software-Bereich manchmal erst suchen muss.


    Bitte nicht böse nehmen, aber das fällt auf ...




    Manche Teile der Argumentation hier verstehe ich übrigens nicht ganz:


    Daily-Build (bzw. solche nach SVN-Commits) wären nur für Entwickler gut heißt es, nicht aber für "normale" Benutzer.


    Angenommen heute baut Hepi nach einem Merge vom Trunk in den Branch ein neues Paket. Morgen dann kommt ein kleiner EPG-Bugfix in den Branch hinzu --> der Rest aber bleibt gleich.


    Was genau hat denn der normale Benutzer davon nun 2 Wochen auf diesen Fix warten zu müssen. Wer überhaupt den PVR-Branch verwendet, dem sind die PVR-Funktionen in gewisser Weise wichtig (sonst würde er den Trunk verwenden), und genau deshalb sind solche Änderungen nicht grundsätzlich uninteressant.



    Zitat von "semerchet"

    Nichtmal die xbmc-Leute selbst machen nightly-Builds für linux. Und auch das PPA for XBMC SVN BUILDING ist nicht so aktuell. Man muß sich dort nur mal die build-Historie ansehen, dann weiß man, dass automatische nightly-Builds keine gute Idee sind.


    Das geht in eine gute Richtung meine ich. Ein automatisiertes Packaging muss man ja nicht zwingend zeitgesteuert bzw. per Cron anstoßen ...


    ... es kann ja auch genausogut ein Webinterface geben, im welchem ein Ober-Chef-Wasweißich-Paketbauer (wer auch immer das ist) auf eine Schaltfläche "Jetzt Pakete bauen" klickt, und so er quasi erst wieder nur händisch den Vorgang anstößt - der dann halt automatisch im Hintergrund vonstatten geht.




    hepi nochmals: Deine letzten Beiträge hier finde ich übrigens gut. Darunter kann man sich schon Konkreteres vorstellen. Ich wollte auch niemanden auf den Schlips treten, das nur als Anmerkung ;)


    Und noch was: Falls ich je auf eine Frage von dir stoßen sollte, antworte ich natürlich gerne drauf - Wissen vorausgesetzt - so wie ich es bei einem jeden Anderen auch mache :D

    Dein den Paketbau betreffendes großes Wissen könntest du ja - frei dem Open-Source-Gedanken folgend - in einem Wiki-Artikel gebündelt zusammenschreiben. Gemeinsam könnte man dies dann als mehr oder weniger solide Basis für ein neues Build-Konzept heranziehen.


    Aber ich weiß, besser wäre wohl ich hätte für meine Frage einen eigenen Thread erstellt, damit mehr Personen erfahren von meinem Anliegen ...


    ... wenn ich hier schon vorschlage dem Oberpaketbauer seine Kompetenz zu entziehen (denn was Anderes ist eine Automatisierung nicht)


    Die Ironie dabei liegt darin, dass es sich hierbei ausgerechnet um eine IT-Tätigkeit handelt, die mit Hilfe von IT einer Wegrationalisierung zum Opfer fallen soll ;)


    Ich habe übrigens Verständnis dafür, dass dir so ein Vorschlag missfällt, der letztendlich deine gegenständliche Wichtigkeit als einzigste Paketbau-Instanz untergraben würde.


    Trotzdem aber bin ich mit so einer einfachen Antwort nicht zufrieden, das musst du auch verstehen:


    30 % sind sachlich falsch ... weil ... es ist Quatsch


    ... denn die Pakete builden nicht immer automatisch ...



    Als ob ich mir Letzteres nicht ohnehin schon denken konnte, und ich schlussendlich genau deswegen in diese Richtung gehend gefragt habe.


    Denn ich denke, gerade weil es nicht so einfach ist, und das Erstellen von Builds eben eine durchaus komplexe Tätigkeit darstellt, sollte man sich genaue Gedanken darüber machen, sobald es in Richtung einer Automaisierung geht.


    Zitat

    Wie wichtig ist es für Dein Leben, jeden Tag neue XBMC-Pakete zu installieren, die nicht funktionieren?


    Was das Funktionieren betrifft wäre man ungefährt dort, wo man jetzt auch schon mit deinen Paketen ist.


    Als ob derzeit Regressions fremd wären, oder nach so einem fehlerhaften Update mittels Paketverwaltung ein Downgrade zurück zur guten, vorherigen Version möglich wäre ... Habe erst gestern Abend mit der unvollständigen 20er-Version mein gesamtes System zerschossen, nachdem die Paketverwaltung mich glauben lassen wollte, sie wäre schon vollständig verfügbar und zur Installation bereit.


    Also alles wie gehabt ;) (bzw. besser, denn ich würde ein gleichzeitiges Bereitstellen von mindestens der vorherigen Paket-Version anstreben. Das ist mir ernorm wichtig) :)



    Auf deine obige Anmerkun hin gehe ich sogar weiter, und behaupte, dass gerade ein Merge vom trunk in den pvr-branch eine besonders kritische Phase für die Gesamtstabilität der gesamten Xbmc-Anwendung darstellt.


    Die nach so einem Trunk-Merge erstellten Pakete (deine) wären damit weit gefährlicher als zwischendurch erstellte, die vielleicht nichts als den einen oder anderen - sich ausschließlich auf den PVR-Teil beschränkenen - EPG-Bugfix beinhalten ;)



    Nichts für ungut, aber so sehe ich die Dinge ;)

    Hallo hepi,


    hast du (oder jeamand anderer) eigentlich schon mal angedacht den Paketbau, so wie du ihn dzt. machst, zu automatisieren?


    Neue Pakete gibts im Großen und Ganzen aktuell ja jeweils nach einem Merge vom pvr-testing2 branch mit dem trunk.


    Zwar liegen diese Packaging-Intervalle jeweils zwischen 2 Merges nicht all zu weit auseinander, gerade wenn speziell für den pvr-testing2 branch Bugfixes oder Features bereitgestellt werden, wäre es oft auch interessant, diese auf einfachem Wege gleich direkt austesten zu können.


    Auch sieht es für mich so aus, als ob für eine Paket-Erstellung dzt. doch zum Wesentlichen händische Arbeit notwendig wäre.


    Ich weiß ja nichts Genaues, aber erlaubt es die Codequalität vom Xbmc-Projekt den Bau der Source-Packages für Launchpad immer mit den selben Schritten/Kommandos durchzuführen?


    Falls irgendwie realisierbar (die Automatisierung) könnte ich nämlich die Infrastruktur bereitstellen, um Nightly-Builds vom pvr-testing2 branch für Ubuntu/Karmic erstellen zu lassen.


    Solch automatisierte Builds aus einem SVN-Repository sind in der Softwareentwicklung ja nichts Außergewöhnliches, und ich denke ein neues Xbmc-Pvr-Paket für jeden Tag, an dem ein Commit in den pvr-branch stattgefunden hat, wäre sicherlich eine feine Sache ... ;)

    Hallo!


    Ich bin bei meiner Nutzung von Xbmc mit VDR und dem Streamdev-Plugin schon auf ein paar Bugs gestoßen, die ich gerne im Bugtracking-Tool einmelden möchte, da es sich dabei scheinbar teils um sehr selten auftretende Probleme handelt.


    Gibt es dazu einen Leitfaden bzw. eine Art common practice, wie so ein Bug-Report aussehen und im Tool landen soll, damit die Entwickler dahinter auch tatsächlich aus den Infos darin größtmöglichen Nutzen erzielen können?


    Denn erst gestern habe ich eingemeldet, dass in neueren Versionen beim Umschalten auf einen TV-Kanal - wenn dieser nicht abgespielt werden kann - nach ein paar Sekunden Wartezeit keine Fehlermeldung mehr erscheint, sondern der gesamte XBMC-Prozess hängen bleibt.


    http://www.xbmc.org/trac/ticket/8611


    Der wurde mir heute aber geschlossen, mit dem Kommentar "Branch bug. closing"


    Verlinkt ist der scheinbar anderswo liegende Original-Bug zu diesem so augenscheinlichen Duplikat aber nicht. Weiß da jemand weiter?



    Denn was nicht das Ziel hinter meiner Bug-Einmelderei ist, das ist das Schließen desselben eines Formfehlers wegen, wenn dabei der eigentliche Sinn dahinter - ein gezieltes Lenken der Entwickler-Kapazitäten mit deren Aufmerksamkeit auf ein punktuell auftretendes, konkretes Problem - auf der Strecke bleibt.