Super. Danke.
Wäre es eigentlich möglich, die youtube
-Id, die es nun im ScheduleLegacy-Object gibt, auch beim NormalizedSchedule
mitzugeben?
Gibt es die Typescript-Types als Package auf npmjs?
Derzeit nicht. Ich schließe nicht aus, dass das noch kommt, aber vorerst kann man ja mit denen aus dem Github-Repo arbeiten
An dieser Stelle kurz vorm WE mal ein Danke und Chapeau an die Jungs für die OAuth-Implementation. Von vorne bis hinten reibungsloser Flow vom Erstellen einer App über die Verifizierung bis hin zur OAuth-Schnittstelle selbst. Funktionierte einfach alles out-of-the-box und ohne Probleme.
Habe meine Rocket Beans Social Wall - #53 by Cyberblitzbirne damit problemlos mit einem rocketbeans.tv-Account-Login ausstatten können, und es läuft tadellos. Chapeau und Danke dafür, @DoomDesign @Yezirael @Kohbrax.
Einen kleinen Verbesserungsvorschlag hätte ich bei den Nutzungs- und Datenschutzbedingungen, die man für seine App eingibt: Wäre schön, wenn Zeilenumbrüche bzw. Absätze aus dem Textfeld auch im Modal des OAuth-Constent Screens übernommen würden. Derzeit ist der Text im Modal ganz ohne Umbrüche, was ihn IMO schwer zu lesen macht.
Vielen Dank. Freie Daten für frei Bohnen!
Besonders geil finde ich ja die Zahl der aktuellen Stream-Views auf YT und Twitch. Ich hab beim Beansgraph mir was eigenes basteln dürfen. Wenn ich im nächsten Monat mal Zeit habe werde ich den Beansgraph auf die API portieren und damit reaktivieren. Und vielleicht auch noch etwas verbessern.
Auf der /v1/schedule/normalized
Route bekommt man ja auch die duration
(sec) und durationClass
zurück. Jetzt frage ich mich, was es mit der durationClass
auf sich hat.
Vielleicht hilft dir das hier weiter? So werden sie generiert:
public static getFrontendDurationClass(duration: number): number {
if (duration > 13500) {
return 4;
} else if (duration > 9900) {
return 3;
} else if (duration > 6300) {
return 2;
} else if (duration > 2700) {
return 1;
} else {
return 0;
}
}
Ist nur fürs Websiten-Frontend, weil ich an die einzelnen Schedule-Items je nach Länge eine Klasse anhänge, welche die prozentuale Höhe bestimmt (damit längere Items optisch mehr Platz einnehmen).
Achso, danke für die schnelle Antwort.
Eine Game Two, oder RocketBeans App, für Android und die PS4 wären klasse für Android mit Benachrichtigungs funktion Und evtl SendungsAbo LG
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.