bitte ignorieren, ich bin dümmer als ich dachte
Zur folgendem Websocket Event habe ich mal eine Frage:
AC_STREAM_INFO
Die laufende Sendung hat sich geändert
(beinhaltet außerdem die aktuelle Livestream URL, sowie die aktuelle Zuschauerzahl)
Das beinhaltet folgendes Objekt/Interface:
export interface streamInfoShow {
title: string;
topic: string;
game: string;
type: tMediaType;
showId: number;
timeStart: Date;
timeEnd: Date;
progress: number;
viewers: streamCount;
};
Unter welchen Bedingungen gilt “Die laufende Sendung hat sich geändert”?
Zählt z.B. auch dazu, wenn die Sendung verlängert wird und sich damit timeEnd und progress ändern? Oder gibts das nur bei komplettem Sendungswechsel?
Ich habs noch nicht getestet und dachte, ich frage mal lieber direkt nach.
Ja, Änderungen an der laufenden Sendung zählen auch dazu.
Sieht man auf der Website manchmal, wenn der Fortschrittsbalken der Sendung verlängert wird (), die Sendung selbst aber nicht wechselt.
Ich implementiere gerade ein paar Kleinigkeiten. Mir ist dabei aufgefallen, dass ihre keine Cache-Control-Header mitschickt. Jetzt muss ich mir Clientseitig eine Cachingstrategie überlegen.
Hintergrund: ich brauche relative häufig die Bohnen-Profile und würde es gerne vermeiden, euch damit tausendfach abzufackeln.
Es wäre schön, wenn ihr die Cache-Control-Header entsprechend setzen könntet (das sind für Bohnenprofile sicher andere als für den Sendeplan ).
Grüße!
Könnt ihr noch auf die Fragen eingehen, die ich in diesem Thread oben gestellt hatte?
@baukran ich hole mir die Profile genau wie von dir beschrieben über bohne/portrait/all.
Ich habe mir jetzt mal eine TTL von 30 Minuten ausgedacht, die ist natürlich genau so gut wie 5 Minuten oder 24 Stunden
@skceb
Guter Einwand ich werde das mal entsprechend auf die Todo setzen, kann jedoch etwas dauern bis wir dazu kommen / es ausrollen
@baukran
Sorry hab vergessen zu antworten :(,
derzeit gibt es kein Ratelimit / steht auf der TODO daher kann ich zu etwaigen Limits noch nicht viel sagen außer dass - wenn sie eingeführt werden sie vermutlich eher großzügig und nicht einschränkend ausfallen werden.
Generell ist es aber nicht falsch möglichst requestsparend zu arbeiten
Die Endpunkte sind falsch in der Dokumentation (wird gleich gefixed)
Richtig wäre: https://api.rocketbeans.tv/v1/media/episode/byshow/304 sowie
https://api.rocketbeans.tv/v1/media/episode/byshow/unsorted/304
sowie jeweils die preview
https://api.rocketbeans.tv/v1/media/episode/byshow/preview/304 und
https://api.rocketbeans.tv/v1/media/episode/byshow/unsorted/preview/304
RBTV OAuth 2.0 Library/Package für PHP 5.6 / 7.x
Für alle, die mit PHP arbeiten (), habe ich mal eine RBTV OAuth2 Library für PHP erstellt, die den Authentication Flow und die Interaktion mit den API-Endpunkten etwas streamlined, vor allem die authenticated endpoints. Damit ließe sich bspw. recht einfach ein RBTV-Social-Login als WordPress-Plugin entwickeln o.ä.
Verfügbar auf GitHub und Packagist zur Nutzung mit Composer oder jedem anderen beliebigen Dependency Manager für PHP.
Fragen, Bugs, Drohungen bitte direkt als Ticket auf GitHub. Pull Requests sind auch jederzeit willkommen.
Ich habe meine Anfrage zur Verifizierung nun mal gestellt. Ich würde mich freuen, von euch zu hören! Liebe Grüße.
Ist geplant, noch ein paar mehr allgemeine Daten per API zur Verfügung zu stellen? Ich bin zufällig gerade an einem RBTV-Projektchen für die Uni zum Thema Datenvisualisierung, und dafür habe ich Daten wie die Anzahl an Youtube-Abos, Anzahl der Forenmitglieder, Anzahl der RBSC-Mitglieder etc. hardcoded reingeschrieben. Die Anzahl der Live-Zuschauer lese ich mir schon aus, sind da kurzfristig weitere Möglichkeiten angedacht?
Hi,
ist es irgendwie möglich herauszu finden, welche Bohne gerade im Stream ist? Bein bisheriger Gedanke war, mit “https://api.rocketbeans.tv/v1/schedule/legacy/current” die ID herleiten und mir dann die Show anzeigen zu lassen, aber mit dieser ID bekomme ich mit “https://api.rocketbeans.tv/v1/media/episode/byshow/:id” nichts heraus.
Da der legacy
-Sendeplan veraltet ist, würde ich mir über den neuen Endpunkt https://api.rocketbeans.tv/v1/schedule/normalized?startDay=1561586400&endDay=1561637718 alle heutigen Sendungen holen und über timeStart
und timeEnd
eingrenzen, welche Sendung gerade läuft. So hast du nur einen API-Request, ohne über die Show-ID oder Episoden-ID noch weitere Requests zu den Bohnen machen zu müssen.
Im bohnen
-Objekt hast du alle teilnehmenden Bohnen der laufenden Sendung.
Vlt etwas hässlich, aber versuchs mal über
/frontend/init. Da steht in der frontendInitResponse unter streamInfo.info alles zur derzeit laufenden Sendung, das müsste dann die richtige ID sein.
Wie ist das bei derzeit laufenden Live-Sendungen oder Premieren? Wenn bspw. ein neues Moin Moin läuft, das noch nicht in Eure Webseiten-Mediathek importiert wurde. Dann würde man sie noch nicht über die showId
oder episodeId
finden können, weil die Id noch 0
wäre in der API, oder? Scheint zumindest beim heutigen “MoinMoin #1113” so.
Gib mir mal den API-Pfad, den du für das MoinMoin 1113 abfragst
Das „MoinMoin #1113“ scheint mittlerweile eine episodeId
zu haben (im /schedule/normalized
Endpoint). Momentan hat aber bspw. „Pfiffige Ziffern #4“ eine episodeId
von 0
in der API. D.h. wenn das nachher läuft und @Ktanka möchte über die episodeId
die OnAir-Bohnen abfragen, könnte er das ja nicht, da die episodeId
0 ist, oder?
Wie oben vorgeschlagen, würde ich es ja eigentlich eh über https://api.rocketbeans.tv/v1/schedule/normalized?startDay=1561586400&endDay=1561637718 abfragen. Da stehen die teilnehmenden Bohnen direkt dabei im bohnen
-Objekt. Da spart man sich einen 2. API-Request auf die Episode über die Id.
Ach stimmt, die Bohnen stehen ja nicht in der Show, sondern in der Episode. My bad!
Find’s übrigens sehr drollig, dass alle Felder der API englische Namen haben (durationClass, duration, streamExclusive etc.), während das OnAir-Bohnen-Objekt deutsch bohnen
heißt. Irgendwie sympathisch.
bohnen™
Danke für die Rückmeldung. Damit klappt es ziemlich gut. Da reicht ein Request aus für die ganze Woche ^^.