Muggle 0.1.1 Beta

übrigens muggle läuft bei mir wieder (vdr-1.3.19)
musste nur in vdr_player.c das so ändern wie beim mp3 plugin:
http://vdr-portal.de/board/thr…?postid=254412#post254412

Zitat

Original von hotzenplotz5
übrigens muggle läuft bei mir wieder (vdr-1.3.19)
musste nur in vdr_player.c das so ändern wie beim mp3 plugin:
http://vdr-portal.de/board/thr…?postid=254412#post254412

Danke, ich habe das übernommen. Bei mir mit AC3 geht es so auch noch.

Wolfgang

Zitat

Original von marsipulami0815
Wegen das Pfades für die m3u's: Die sollten meiner Meinung nach dort gespeichert werden, wo auch die MP3 Dateien liegen, nicht im etc/vdr/plugin-Verzeichnis. Wenn man es über einen Eintrag in einer Config-Datei steuern kann, dann ist das schon ok. Ändert man (ich) ja nicht täglich ;)Marcus

Ich persönlich werde garantiert immer alles versuchen, Einträge in der Configdatei zu vermeiden.

Das Verzeichnis mit den mp3 - Files (Top Level Directory) könnte auch readonly sein, also kann man das nicht fix nehmen.

Nun haben Lars und ich für die nächste Version etwas anderes ausgedacht (habe ich auch schon programmiert und getestet):

Alle *.m3u Files kommen nach /tmp, und sie enthalten die Dateinamen relativ zum Top Level Directory.

Externe Befehle werden sinngemäss so aufgerufen:

cd $Topleveldir && command /tmp/soundso.m3u

wobei command aus playlist_commands.conf kommt

Wenn Du die *.m3u also in /Topleveldir haben willst, kannst Du einen externen Befehl definieren, der einfach so aussieht: mv "$1" .

Irgendwann, wenn die möglichen Befehle überhand nehmen, gibt es dann vielleicht ein Setupmenü, in dem man angeben kann, welche Befehle man nie sehen möchte. Dann könntest Du also den fest programmierten Exportbefehl transparent durch Deinen eigenen ersetzen.

Wolfgang

Hi,
vor einem Abspeichern der m3us im "mp3-Verzeichnis" taete ich auch eher abraten, da:
(i) z.B. sich dort (bei mir ist das so) schon einige nicht mit muggle angelegten playlisten befinden koennen
(ii) "Fremdanwendungen" Probleme bekommen koennten (oder benutzt ihr alle nur muggle --> schon das mp3-plugin arbeitet dann nicht mehr wirklich unabhaengig) ...
Ein eigenes temp-Verzeichnis (also auch nicht /tmp , sondern /tmp/muggle) faende ich da etwas geschickter).

Ich mache mir uebrigens (hat nur teilweise etwas mit dem VDR zu tun) momentan Gedanken bzgl. einer Multiuser-Jukebox (denke immer noch, dass auch der VDR mal ein richtiges Multiuser-System werden koennte), d.h. alle clients greifen auf den gleichen Datenbestand zu und legen serverseitig temporaere playlisten an, wobei diese wieder eindeutig dem client zugeordnet werden muessen.
Muss gestehen, dass ich mir immer noch nicht die Giantdisc/Muggle-DB genauer angesehen habe, doch ist da auch soetwas wie eine Userverwaltung implementiert/angedacht (nicht jeder User muss/soll unbedingt das ganze Archiv sehen) ?
Gruss
Burkhardt

Zitat

Original von burki
Muss gestehen, dass ich mir immer noch nicht die Giantdisc/Muggle-DB genauer angesehen habe, doch ist da auch soetwas wie eine Userverwaltung implementiert/angedacht (nicht jeder User muss/soll unbedingt das ganze Archiv sehen) ?

Soviel ich weiss, nein.

ich würde auch gerne alles vermeiden, was die SQL - Abfragen langsamer machen könnte. Zumindest bis klar ist, ob es aus der Richtung her Probleme geben könnte. So eine Liste kann schon mal ein paar Tausend Einträge enthalten, und die muss man auch erstmal holen und daraus ein VDR-Menü machen.

Warum nicht einfach separate Datenbanken pro User?

Wolfgang

Hi.

Hat das wirklich keiner kompiliert ?

Oder könnte das bitte jemand für mich tun ?

Gruß Manni.

Hi,

Zitat

Wenn schon, dann muss der VDR zB erstmal die Sprache, Recordingmenüs, etc. umschalten können, wenn jmd anders die FB in die Hand nimmt. Dann sehen wir mal weiter...

nunja, mein Framework hat nur teilweise etwas mit dem VDR zu tun (Clients sind z.B. ein Pinnacle-SC, diverse Browser, Java-Clients, ...).
Es ging mir auch weniger (hab mich oben missverstaendlich ausgedrueckt) darum, dass mehrere User einen Client benutzen, sondern viele Clients auf einen Medienbestand (bzw. auf die davon generierten playlisten) und eine zentrale DB zugreifen, der auf einem VDR-Server liegt.
Und ich wollte nur vorsichtig nachfragen, was sich eben in der DB so grundlegend noch aendern koennte.

Zitat

Warum nicht einfach separate Datenbanken pro User?

das sehe ich eigentlich auch nicht als die Loesung an, denn dann faengt man wieder an, bei Aenderungen im Datenbestand alle DBs zu aktualisieren ...
Gruss
Burkhardt

Zitat

Original von wolfgang61
Ich persönlich werde garantiert immer alles versuchen, Einträge in der Configdatei zu vermeiden.

Ich meinte auch nicht die setup.conf, sondern eine muggle.conf im Plugins-Unetrverzeichnis des VDR-Config Verzeichnisses.

Zitat

Das Verzeichnis mit den mp3 - Files (Top Level Directory) könnte auch readonly sein, also kann man das nicht fix nehmen.

Stimmt, deswegen sollte das auch nicht fix sein.

Zitat

Nun haben Lars und ich für die nächste Version etwas anderes ausgedacht (habe ich auch schon programmiert und getestet):

Alle *.m3u Files kommen nach /tmp, und sie enthalten die Dateinamen relativ zum Top Level Directory.

Externe Befehle werden sinngemäss so aufgerufen:

cd $Topleveldir && command /tmp/soundso.m3u

wobei command aus playlist_commands.conf kommt

Wenn Du die *.m3u also in /Topleveldir haben willst, kannst Du einen externen Befehl definieren, der einfach so aussieht: mv "$1" .

Alles anzeigen

Dazu muss ich dann die playlist_commands.conf pflegen. Ich bevorzuge halt, die Playlisten in einem eigenen Unterverzeichnis zu haben, meinetwegen auch z.B. /tmp/muggle_playlists/xyz.m3u oder so ähnlich. Dieses Unterverzeichnis kann ich mir ja dann verlinken, wohin ich will...(schlägt burki ja auch so vor)

Zitat

Irgendwann, wenn die möglichen Befehle überhand nehmen, gibt es dann vielleicht ein Setupmenü, in dem man angeben kann, welche Befehle man nie sehen möchte. Dann könntest Du also den fest programmierten Exportbefehl transparent durch Deinen eigenen ersetzen.

Ich sehe im Moment noch nicht, welche Befehle ich so auf m3u's loslassen könnte, ausser die abzuspielen

Gruß,
Marcus

Zitat

Original von burki
[...]
Ich mache mir uebrigens (hat nur teilweise etwas mit dem VDR zu tun) momentan Gedanken bzgl. einer Multiuser-Jukebox (denke immer noch, dass auch der VDR mal ein richtiges Multiuser-System werden koennte), d.h. alle clients greifen auf den gleichen Datenbestand zu und legen serverseitig temporaere playlisten an, wobei diese wieder eindeutig dem client zugeordnet werden muessen.
Muss gestehen, dass ich mir immer noch nicht die Giantdisc/Muggle-DB genauer angesehen habe, doch ist da auch soetwas wie eine Userverwaltung implementiert/angedacht (nicht jeder User muss/soll unbedingt das ganze Archiv sehen) ?
Gruss
Burkhardt

Hi Burkhardt,

hast Du Dir schon mal Ampache angesehen? Fährt zwar auf 'ner eigen DB in mysql, aber dort gibt es eine Benutzerverwltung, die alles das kann, was Du oben beschreibst.
Ich habe Ampache hier auch laufen, greift auf den gleichen Datenbestand zu wie muggle (und auch das MP3-Plugin) und falls ich direkt von Windows aus auf die MP3's zugreifen will, geht das über ein Samba share. Ich kann sogar auf Ampache von "draussen" zugreifen (dank DynDNS) , dafür reichen auch noch die 128kBit uplaod Geschwindigkeit vom DSL...

Gruß,
Marcus

Hi Marcus,
ja, ueber dieses und eine Vielzahl andere Programme bin ich schon gestolpert, doch der Musikpart (die meisten koennen da eh nur mit mp3 und ogg umgehen) ist nur ein Teil des Ganzen bei mir und ich hab eh schon einen Grossteil der Anwendung geschrieben (bisher ohne DB, d.h. tags werden on-the-fly gelesen und ohne Clientverwaltung --> deshalb meine obige Frage, denn mit der Zeit wird sich sicher die Muggle-DB auch fuer Dinge wie EPG, DVDs, Aufnahmen, ... anbieten).
Zudem taugen all diese Klickanwendungen wenig, wenns z.B. um WAP oder bestimmten Streamclients geht.
Aber ich moechte jetzt nicht den hiesigen thread kaputtreden ...
Gruss
Burkhardt

Hallo.

mysql hab ich zu laufen bekommen ( schaut zumindest so aus ).
Da gibts ja einen Thread ( ich glaube von decembersoul) zu dem Thema.
Mir fehlt jetzt das plugin und das "Zubehör" ( mugglei und was es sonst noch geben mag).

Gruß Manni

Es wäre schön wenn noch die Parameter für muggle aufzurufen erklärt würden. (Ich habe sie leider nicht alle so auf Anhieb im README gefunden.)

-w steht hier also für das Passwort. Weicht etwas von den mugglei parametern ab. Naja einfach mal in den Quellcode zu muggle geschaut.

Der Import funktioniert auch nur wenn man jeweils mit -p auch die Passwortabfrage einbezieht. sonst hagelt es mysql Fehlermeldungen.
Evtl kann man das noch in der Readme anpassen.

Ansonsten wie immer großes Lob.

Gruss,

Jörg

Hi, ich nutze zur Zeit ein GD Server und würde gerne auf muggle umstellen. (eine Kiste weniger). Das GD steuere ich über ein SIMPAD / Browser mit dem Webfrontend http://gd.philsworld.de/screenshots/. Wäre diese Browseroberfläche auch mit muggle machbar ?
Gruß HAL

Völlig OT:

Ich hab jetzt auch muggle mal ausprobiert (und da ich letztens Ampache installiert hab, konnte ich mich auch dazu durchringen, meine MP3s endlich mit einem sinnvollen ID3 Tag zu versehen ;)), aber jetzt hab ich nur ein Problem.

Als Suchschema hab ich Album -> Title, was auch soweit passt, aber wie bekomme ich muggle dazu das album in der korrekten Reihenfolge abzuspielen (Tracknummer ist im Tag vorhanden, und in der Datenbank wird es ja auch erfasst).

Sicher irgendeine Dämlichkeit von mir, dass ich das irgendwie nicht finde ;))

Zitat

Original von Konni__Als Suchschema hab ich Album -> Title, was auch soweit passt, aber wie bekomme ich muggle dazu das album in der korrekten Reihenfolge abzuspielen (Tracknummer ist im Tag vorhanden, und in der Datenbank wird es ja auch erfasst).

da bist Du nicht der Erste. Du könntest nach einem alten Beitrag suchen, in dem steht, wie man das in der Source ändern kann, oder auf die nächste Version warten (in den nächsten Tagen). Da kannst Du dann Sortierungen beliebig selber definieren - auch, ob nach Titel oder Tracknummer sortiert. Man kann dann u.a. auch die Sprache mit mugglei importieren und auch danach sortieren. Und die Genres hierarchisch durchsuchen wie auf der Homepage vom Giantdisc beschrieben.

In der heutigen Source müsstest Du in mg_actions.c die Definition zu mgSearchAlbumTitle::NewSearch ändern, "Title" durch "Track" ersetzen. Und wenn Du willst auch darüber in MenuName, das wäre aber nur optisch.

Wolfgang