Ubuntu-Pakete XBMC-PVR-Testing auf aktuellem Entwicklungsstand verfügbar

  • Ich bin ja kein XBMC-Entwickler, meinen letzten selbstentwickelten Patch für XBMC habe ich im Mai an pingpong geschickt. Ich baue ja nur und melde Bugs.


    Also, mittlerweile gibt es im Branch XBMC-PVR-Testing2 sogar mehrere PVR-Klienten: vdr-streamdev und einen Client für mediaportal. Zusätzlich gibt es experimentellen Support für TV-Headend. Je mehr unterschiedliche PVR-Clients es gibt, desto weniger wird möglicherweise auch der VDR als Backend im Mittelpunkt stehen.


    Das zeigt doch, dass das Thema PVR in XBMC an Bedeutung gewinnt. Meine persönliche Einschätzung: Angenommen, das nächste XBMC-Release wird wie geplant im Mai erscheinen (10.5). Dann wird man sich spätestens im März/April entscheiden müssen, ob PVR-Testing stabil genug ist, um der Welt zugemutet zu werden. Wenn ja, dann wird es im März/April in den trunk geschoben, dort wird weiterentwickelt und der Branch pvr-testing2 ist damit obsolet.


    Dann ist die Frage, welche bis dann verfügbaren PVR-Klienten stable sind und welche nicht. Vielleicht werden unstable PVR-Clients nicht geshippt mit dem Release und man muss diese weiterhin selber bauen.


    Was wir dann in Zukunft selber bauen müssen, ist unklar, aber es wird weniger sein.


    Gruß
    hepi


  • Hi,
    du hast völlig recht mit allem. 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.


    Mal abgesehen davon, wenn man so scharf auf aktuelle svn-Builds ist, ist der Aufwand mit svn update und kompilieren mit ccache sehr überschaubar.


    Gruß

  • hi


    so hab nun die neuen hepi pakete installiert und konnte zu der letzten version eigentlich keine wesentlichen veränderungen feststellen. beide sehr stabil - vor allem was den epg angeht deutlich brauchbarer (wird nachgeladen wenn man zu früh in den tv modus geht).


    was irgendwie verschwunden ist ist der punkt "tv-aufnahmen" unter videos. allerdings war der sowieso unbrauchbar (es wurden immer die falschen aufnahmen abgespielt). der menüpunkt aufnahemn unter live tv liefert das gleiche problem (immer falsche aufnahmen). die darstellung gefällt mir jedoch sehr gut. weis jemand wie genau das funktioniert? werden die aufnahmen dann vom vdr gestreamt? ließt xbmc die entsprechenden daten ein oder kommen die vom streamdevserver?


    mfg

  • 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

  • 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.

  • Löwe, mache bitte einen neuen Thread auf für Dein Konzept, das möglicherweise gar nicht Ubuntu-spezifisch ist. Bitte diskutiere das Thema dort, bevor mir hier gleich noch sehr sarkastische Kommentare einfallen und ich mich nicht mehr zurückhalten kann, auf die polemische Ebene zu wechseln.


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


    Ich wünsche Dir viel Erfolg mit Deinem Projekt der Build-Automatisierung.


    Gruß
    hepi

  • 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?

  • Zitat

    Original von löwe


    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 soll denn der Mist? Warum bohrst du ständig nach? Der Build-Prozess steht doch für Jeden zugänglich in den Paket-Sourcen.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • 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 ...

  • Hallo Hepi,


    zunächst auch von mir einen fetten Dank für Deine Arbeit.


    Ich hab' heute mal alles bzgl. xbmc inkl. ~/.xbmc gelöscht, weil ich kein LiveTV mehr hatte.


    Nachfolgend habe ich alles von Dir neu installiert ... aber ich finde den Menu-Punkt TV nicht mehr.
    EDIT: Das ist NICHT die Kiste aus der Signatur !


    Irgendwie sehe ich den Wald vor lauter Bäumen nicht.


    Kann mich mal jemand wachrütteln ... bitte.


    Danke Miru

    VDR-Server 2.0.6 yavdr-testing-repo - Kubuntu 12.04 LTS/64 - I-Dual-Core 2,2 GHz, 2 GB RAM, SATA 500GB, via NFS 2,9 TB HW-RAID5 an Sol10Sparc mit ZFS, 1x FF-TT 2.3 modded, 1x FF-TT 1.5, 2x TT-1600, via DLAN AVpro/Coax 4x 2x MVP Ver.D3A - VOMP 0.4.0 mit Media, MVP-Dongle 0.4.0
    Arbeitsplatz: 12.04 LTS/64 2.0.6
    yavdr-testing-repo - I-Dual-Core 2,4 GHz, 4 GB RAM, 2x 1TB, 2x TT-1600
    WAF-VDR-Client: openelec-3.2.4/XBMC-12.2-Frodo/ alternativ yavdr 0.5.0a: PulseEight-USB-CEC-Adapter, ZBOX-HD-ID41: 4GB RAM, 64GB SSD, 16GB Patriot-USB-Stick am Samsung UE37D5700 (gehackt) für TimeShift direkt am TV ohne VDR-Zugriff

    Einmal editiert, zuletzt von Miru ()

  • Nach einer Neuinstallation/Update möchtest Du bitte erst den TV-Client wieder aktivieren: System -> Einstellungen -> TV


    BJ1


    Edit: Hepi war schneller ;)

    Einmal editiert, zuletzt von BJ1 ()


  • Hi,


    System -> TV ist nicht da?


    Also ich hatte ähnliches Erlebnis schon mal nach "apt-get upgrade", weil ich sowohl hepi's ppa als auch das ppa von team-xbmc eingebunden hatte, und einfach auf das falsche xbmc geupgradet habe. Vielleicht ist es ähnlich bei dir?


    Gruß

  • Hallo Hepi,


    genau da ist mein Problem ... unter Settings gibt es kein TV.


    Bei meinem Dell Mini 11z mit ebenfalls Kubuntu 9.10 und Deinen Paketen ist er da und lässt sich auch super auf den Server meiner Signatur konfigurieren.


    Nur bei diesem meinem Arbeitsplatzrechner, welcher den aktuellen vdr vom the-vdr-team hat, ist der Punkt verschwunden ... hab' ich irgendwas vergessen bzw. übersehen ... bin leider auch schwer erkältet und mein Kopf brummt wie 'n Traktor.


    Gruß Miru

    VDR-Server 2.0.6 yavdr-testing-repo - Kubuntu 12.04 LTS/64 - I-Dual-Core 2,2 GHz, 2 GB RAM, SATA 500GB, via NFS 2,9 TB HW-RAID5 an Sol10Sparc mit ZFS, 1x FF-TT 2.3 modded, 1x FF-TT 1.5, 2x TT-1600, via DLAN AVpro/Coax 4x 2x MVP Ver.D3A - VOMP 0.4.0 mit Media, MVP-Dongle 0.4.0
    Arbeitsplatz: 12.04 LTS/64 2.0.6
    yavdr-testing-repo - I-Dual-Core 2,4 GHz, 4 GB RAM, 2x 1TB, 2x TT-1600
    WAF-VDR-Client: openelec-3.2.4/XBMC-12.2-Frodo/ alternativ yavdr 0.5.0a: PulseEight-USB-CEC-Adapter, ZBOX-HD-ID41: 4GB RAM, 64GB SSD, 16GB Patriot-USB-Stick am Samsung UE37D5700 (gehackt) für TimeShift direkt am TV ohne VDR-Zugriff

  • Code
    rumi@RumiDell:~$ dpkg --list | grep "xbmc" 
    ii  xbmc                                       pvr-testing-20~hepi-karmic27127                            XBMC Media Center (full metapackage) 
    ii  xbmc-bin                                   pvr-testing-20~hepi-karmic27127                            XBMC Media Center (binary data package) 
    ii  xbmc-data                                  pvr-testing-20~hepi-karmic27127                            XBMC Media Center (arch-independent data package) 
    ii  xbmc-skin-confluence                       pvr-testing-20~hepi-karmic27127                            XBMC Media Center (Confluence skin) 
    ii  xbmc-web-pm3                               pvr-testing-20~hepi-karmic27127                            XBMC Media Center (Project Mahem III web skin)


    Danke Miru

    VDR-Server 2.0.6 yavdr-testing-repo - Kubuntu 12.04 LTS/64 - I-Dual-Core 2,2 GHz, 2 GB RAM, SATA 500GB, via NFS 2,9 TB HW-RAID5 an Sol10Sparc mit ZFS, 1x FF-TT 2.3 modded, 1x FF-TT 1.5, 2x TT-1600, via DLAN AVpro/Coax 4x 2x MVP Ver.D3A - VOMP 0.4.0 mit Media, MVP-Dongle 0.4.0
    Arbeitsplatz: 12.04 LTS/64 2.0.6
    yavdr-testing-repo - I-Dual-Core 2,4 GHz, 4 GB RAM, 2x 1TB, 2x TT-1600
    WAF-VDR-Client: openelec-3.2.4/XBMC-12.2-Frodo/ alternativ yavdr 0.5.0a: PulseEight-USB-CEC-Adapter, ZBOX-HD-ID41: 4GB RAM, 64GB SSD, 16GB Patriot-USB-Stick am Samsung UE37D5700 (gehackt) für TimeShift direkt am TV ohne VDR-Zugriff

    Einmal editiert, zuletzt von Miru ()

  • hepi,


    so, da ha'm wir dat Problem ...

    Code
    rumi@RumiDell:~$ whereis xbmc xbmc: /usr/bin/xbmc /usr/lib/xbmc /usr/local/bin/xbmc /usr/share/xbmc /usr/share/man/man1/xbmc.1.gz

    Ich muss wohl mal richtig aufräumen ... mach' ich später, weil ich mich ums Essen für's Töchterlein kümmern muss.


    Grazie Miru

    VDR-Server 2.0.6 yavdr-testing-repo - Kubuntu 12.04 LTS/64 - I-Dual-Core 2,2 GHz, 2 GB RAM, SATA 500GB, via NFS 2,9 TB HW-RAID5 an Sol10Sparc mit ZFS, 1x FF-TT 2.3 modded, 1x FF-TT 1.5, 2x TT-1600, via DLAN AVpro/Coax 4x 2x MVP Ver.D3A - VOMP 0.4.0 mit Media, MVP-Dongle 0.4.0
    Arbeitsplatz: 12.04 LTS/64 2.0.6
    yavdr-testing-repo - I-Dual-Core 2,4 GHz, 4 GB RAM, 2x 1TB, 2x TT-1600
    WAF-VDR-Client: openelec-3.2.4/XBMC-12.2-Frodo/ alternativ yavdr 0.5.0a: PulseEight-USB-CEC-Adapter, ZBOX-HD-ID41: 4GB RAM, 64GB SSD, 16GB Patriot-USB-Stick am Samsung UE37D5700 (gehackt) für TimeShift direkt am TV ohne VDR-Zugriff

  • hepi,


    jup, dat war's. Danke für Deine Hilfe.


    Gruß Miru

    VDR-Server 2.0.6 yavdr-testing-repo - Kubuntu 12.04 LTS/64 - I-Dual-Core 2,2 GHz, 2 GB RAM, SATA 500GB, via NFS 2,9 TB HW-RAID5 an Sol10Sparc mit ZFS, 1x FF-TT 2.3 modded, 1x FF-TT 1.5, 2x TT-1600, via DLAN AVpro/Coax 4x 2x MVP Ver.D3A - VOMP 0.4.0 mit Media, MVP-Dongle 0.4.0
    Arbeitsplatz: 12.04 LTS/64 2.0.6
    yavdr-testing-repo - I-Dual-Core 2,4 GHz, 4 GB RAM, 2x 1TB, 2x TT-1600
    WAF-VDR-Client: openelec-3.2.4/XBMC-12.2-Frodo/ alternativ yavdr 0.5.0a: PulseEight-USB-CEC-Adapter, ZBOX-HD-ID41: 4GB RAM, 64GB SSD, 16GB Patriot-USB-Stick am Samsung UE37D5700 (gehackt) für TimeShift direkt am TV ohne VDR-Zugriff

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!