Cutlist.at 2.0 und CuLiX - Brainstormingthread

[anatol.at]

Ideen können hier geposted werden. Das Konzept wird anhand der Ideen nach und nach verfeinert und anschließend hier veröffentlicht:
http://cutlist.at/2.0/

Eine derzeit noch sehr unvollständige und teils sogar noch veraltete Version des Konzeptes sowie ein Zeitplan sind bereits online.

[anatol.at]

Das Problem bei den Bewertungen ist mir sehr wohl bewusst, daher ja mein Ansatz für das neue Bewertungssystem:

Der Autor gibt beim Upload folgende Informationen an:
Ausgangsmaterial: audiofehler | bildfehler | anfang fehlt | ende fehlt | asynchron (bild und ton sind versetzt)
Doppelte Szenen: unbekannt | keine | entfernt | noch vorhanden
Schnittgenauigkeit: perfekt | akzeptabel (1 frame, knacken) | grob

Der Benutzer gibt bei der Bewertung folgendes an:
Schnittgenauigkeit: perfekt | akzeptabel | fehlerhaft
Doppelte Szenen: keine (mehr) | noch vorhanden

Abwärtskompatibilität:
5 = perfekt + keine doppelten szenen
4 = perfekt|akzeptabel + doppelte szenen
3 = fehlerhafter schnitt

---

Dass RSS vielen Benutzern wichtig ist, ist mir bereits des öfteren aufgefallen, darauf werde ich in Zukunft mehr Wert legen.

[benn]

Danke für die Antwort!
Wie ich schon in dem verlinkten Thread aufgeführt habe, würde ich die alten Schnittstellen einfach so lassen und neue Api-Request fürs Runterladen per JSON anbieten: Ein Request – alle Informationen, inkl. Schnittmarken. Ich sehe auch wenig Nutzen darin, an der Cutlist-Datei als solcher zu bleiben. Die Datei muss heruntergeladen, ausgelesen, am Ende gelöscht werden (wenn es per Client geschieht).

[anatol.at]

Hmm, langsam bin ich überzeugt... Also eine neue API die nur noch mit JSON arbeitet und in einem Request die Suchergebnisse inklusive aller Schnittinformationen beinhaltet - und weiterhin Ausgaben in den bisherigen Formaten als XML und ini.

Irgendjemand Argumente dagegen XML nicht vollwärtig zu unterstützen bzw. Argumente gegen JSON?

[benn]

(Die gewünschten Typen casten muss man ja trotzdem noch wenn man es nicht nur anzeigen möchte... -_-)

Ich bin mir nicht sicher, ob dich richtig verstehe, aber: Wenn man den JSON-Parser von PHP oder Python nimmt, wird gleich automatisch gecastet. Wenn man stattdessen die Strings noch casten müsste, wäre ein großer Vorteil von JSON verloren gegangen.

[anatol.at]

Klar, in Java ist es aber tatsächlich so, dass wenn du ein Objekt oder Array parst alles Strings sind! Nicht nur Zahlen sondern auch verschachtelte Objekte, die müssen dann Ebene für Ebene neu geparst werden. Und einfach mit Strings rechnen ist auch nicht möglich. (Daher sind mir dynamisch typisierte Scriptsprachen grundsätzlich viel lieber...)

PS: falls ich hier was falsches behaupte lasse ich mich gerne eines Besseren belehren. ;)

[anatol.at]

Back to topic:
Mist! Ich wusste doch dass wir irgendetwas nicht bedacht haben: die Bewertung auf der Seite basiert darauf, welche Cutlist der Benutzer heruntergeladen hat. Diese Funktion will ich auf alle Fälle beibehalten!

Man könnte natürlich einen zusätzlichen Request senden welche Liste verwendet wurde, aber darauf ist nur bedingt Verlass... (Und es sind erst wieder 2 Requests...)

[benn]

Klar, in Java ist es aber tatsächlich so, dass wenn du ein Objekt oder Array parst alles Strings sind! Nicht nur Zahlen sondern auch verschachtelte Objekte, die müssen dann Ebene für Ebene neu geparst werden. Und einfach mit Strings rechnen ist auch nicht möglich.

Da gibt es bestimmt auch alternative JSON-Parser, aber ich lehne mich mal nicht zu weit aus dem Fenster.


Mist! Ich wusste doch dass wir irgendetwas nicht bedacht haben: die Bewertung auf der Seite basiert darauf, welche Cutlist der Benutzer heruntergeladen hat. Diese Funktion will ich auf alle Fälle beibehalten!

Man könnte natürlich einen zusätzlichen Request senden welche Liste verwendet wurde, aber darauf ist nur bedingt Verlass... (Und es sind erst wieder 2 Requests...)

Das ist natürlich ein Problem.
Vielleicht könnte man es ja wirklich so machen, dass die Clients immer nach dem Schneiden eine Rückmeldung an cutlist.at geben, egal ob bewertet wurde oder nicht.

Beispiel:

/api/rate/id=9012345/cut=1/ds=0 # Nutzer bewertet eine Cutlist
/api/rate/id=9012345 # Nutzer hat Cutlist nicht bewertet, der Client schickt aber trotzdem diesen Request

Das hätte sogar noch einen Vorteil: In der Liste bei cutlist.at würden dann nur die Cutlists zum Bewerten auftauchen, die auch wirklich benutzt wurden, nicht auch eventuelle Test-Dateien, fehlgeschlagene Versuche etc.

[Artemis1121]

vielleicht wäre es auch interessant bei den suchergebnissen zusätzlich zu der durchschnittsbewertung der cutlist die einzelbewertungen zu liefern, so könnte man einfacher möglicherweise falsche bewertungen erkennen: (3*5+1*0)/4 = 3,75 = (3*4+1*3)/4.
auch wäre bei der bewertung schön, wenn nutzer kurze kommentare zu den schnittlisten oder gar einzelnen schnitten abgeben könnten(auflistung in den suchergebnissen optional?)!

[Artemis1121]

was hältst du davon das 1 bis 5 abzuschaffen und dadurch zu ersetzen:
http://www.otrforum.com/showthread.php/62406?p=313034&viewfull=1#post313034 ?

hatte ich gelesen, aber als mapping der neuen werte auf das alte format verstanden(also in db weiterhin 1-5).
hab gerade noch mal genauer gelesen und hätte ich dein beispiel angeschaut wäre der teil meines posts vollkommen überflüssig gewesen! sehr schön eindeutig umgesetzt!

userrating : {
ratingcount : '6',
cuts : { perfect : '5', suitable : '1', unexact : '0' }
duplicatescenes : { removed : '6', stillexisting : '0' }
},

nur ist da ratingcount überhaupt sinnvoll oder nicht eher eine überflüssige fehlerquelle?

von meinem ersten post bleibt nur noch ggf. die idee der benutzerkommentare übrig.

[JanS]

* Ich würde die Sekunden-Angaben völlig abschaffen. Die Clients müssen ja eh umgeschrieben werden – dann würde man sich den Hickhack auch sparen.

Gruß, Benny

Versteh ich das richtig, dass du die Sekundenangaben für die Schnitte meinst? Die würde ich nicht aufgeben. Bei den avis sind Frameangaben sicherlich besser, aber falls sich irgendwann doch noch mkvs durchsetzen sollten, wären für diese die Timestamps die bessere Angabe. Deswegen wird auch Avidemux gerade auf Timestamps umgeschrieben. Außerdem kann man momentan so HQ und HD cutlists untereinander austauschen.

[benn]

Das liegt nicht am Parser sondern an der Sprache. Ein Array kann nur Strings, oder nur Zahlen oder nur Hashtables enthalten, mischen ist nicht möglich!

Ah, jetzt versteh ich's.


Da werden viele zu faul sein es zu implementieren, der Request bleibt hängen, der Server ist gerade überlastet -> timeout... (=nicht verlässlich...)

Naja, jetzt sind die Client-Entwickler ja auch nicht zu faul, eine Bewertung abzuschicken. Der Code ist ja immer schon vorhanden, er muss nur auch ausgeführt werden, wenn der User zu faul ist, zu bewerten.


Aber es soll doch auch möglich sein zu sagen dass eine Liste so schlecht ist, dass ich nur die ersten 2 Cuts angesehen und gar nicht damit geschnitten habe?! Also müsste die Schnittsoftware bei jeder Cutlist die betrachtet wird einen Request senden... (sehr aufwendig für Entwickler... )

Das geschieht doch jetzt auch nicht. Beispiel: Wenn ich einen Film schneide, schaue ich mir mit OTR-Verwaltung 3 Cutlists an. Die beste nehme UND bewerte ich. Die anderen habe ich dann schon vergessen. (Übrigens ein Grund, warum ich nie das cutlist.at-Online-Bewerten nutze – da stehen zu viele Cutlists, die ich nie konkret verwendet habe.) Das ist natürlich jetzt nur meine Position.
Die Funktion, eine schlechte Liste zu bewerten (auch wenn ich glaube, dass das das selten passiert, wenn eine gute Alternativliste vorhanden ist), müsste dann eigentlich im Client vorhanden sein. (Habt bis jetzt noch nie jemand gefordert.)
Das Bewerten ist ja sowieso ein Aufwand, den nicht alle auf sich nehmen.


Versteh ich das richtig, dass du die Sekundenangaben für die Schnitte meinst? Die würde ich nicht aufgeben. Bei den avis sind Frameangaben sicherlich besser, aber falls sich irgendwann doch noch mkvs durchsetzen sollten, wären für diese die Timestamps die bessere Angabe. Deswegen wird auch Avidemux gerade auf Timestamps umgeschrieben. Außerdem kann man momentan so HQ und HD cutlists untereinander austauschen.

Dazu kann ich leider nichts sagen. Aber OTR-Verwaltung arbeitet immer mit Frames, und ich habe noch von keinen Problemen mit HQ/HD-Cutlists gehört.
Hast du vielleicht noch ein paar Quellen dazu?

[ovicula]

- Doppelte Szenen lässt doch keiner drin, zumindest habe ich bis jetzt noch keine CL mit solchen gesehen, und WENN das mal vorkommt, dann aus versehen. Das sollte also m.M.n. nicht extra angeführt werden.

Erlebe ich leider auch häufiger! Sehe ich auch für zwingend an, dass in die Bewertung mit aufzunehmen!

[DanYo187]

Hi!
Na dann korrigiere ich hiermit meine Einschätzung zu doppelten Szenen. Den Rest find ich aber trotzdem sinnvoll ;)
Lg DanYo187

[Artemis1121]

Und bei den Übergängen sollte man es immer so machen, dass die so wenig die möglich sichtbar sind. Hier wird dir kein Mensch ankreuzen, er hätte Störgeräusche oder ähnliches mit Absicht drin gelassen.

an dieser stelle will ich noch mal benutzerkommentare ins gespräch bringen. gerade wenn jemand so etwas negatives feststellt, wäre ein benutzerkommentar denke ich wertvoller als eine schlechte bewertung der cutlist!

[MrR]

Eben nicht, das ist ja das Problem! […] Aus Betreibersicht ist der Kern der derzeitigen Implementierung ohne Planung in wenigen Stunden während eines .de-Ausfalles entstanden und seither kaum verbessert worden. Trotzdem sind es mittlerweile so viel mehr User und Features, dass vor allem das DB-Design einfach nicht mehr nachkommt.
Also Spaghetticode und Redundanzen. ;)
Da ist ein sauber geplanter Neustart auch besser. Dann habe ich nichts gesagt und behaupte das Gegenteil. :)

[MrR]

Dieses Thema gibt es, seit es Cutlisten gibt. Wäre mit v2.0 eine serverseitige Abfrage möglich, um das Hochladen von 1zu1 Cutlisten zu verhindern bzw. diese als eindeutige Kopie zu kennzeichnen?

[anatol.at]

Also Spaghetticode und Redundanzen. ;)
Beinahe erschreckend wie genau es das trifft... ;) Und ein Index obsoleter als der andere... aber mal zu profilen welche es sind bin ich zu faul. :wasntme:



Wäre mit v2.0 eine serverseitige Abfrage möglich, um das Hochladen von 1zu1 Cutlisten zu verhindern bzw. diese als eindeutige Kopie zu kennzeichnen?

Ist möglich und fix geplant. Wenn die Schnitte zu 100% übereinstimmen wird der Upload abgelehnt. Falls der Benutzer registriert ist hat er 1 Stunde lang Zeit um bequem per Klick auf einen Link zur Sendung direkt auf der Startseite Zusatzinformationen (Tags, Ratio, Fehler,...) anzugeben.

[SGE]

Halte ich für völlig unnötige Spielerei. Wenn ich ne CL brauche und es gibt keine mach ich sie mir selber.