neurowhai / isekaidol-stream-noti Goto Github PK

방송 화면에선 새로고침하면 제목 바뀌어있는데 API는 한참 지나서야 반영되어 알림이 늦게 송출됨.
거의 1분 늦는 경우가 있었음.
정말 API의 정보가 늦게 반영되는 것인지 아니면 오류로 아예 못 받아서 스킵된건지 알 수 있게 바꿔두었으니 추후 오류 확인.

릴단콘처럼 유튭에서만 라이브 진행하는 경우가 통신사들 덕분에 생길 수 있음.
API를 쓰려고 했는데 너무 번거롭게 되어있음.
채널ID/live의 HTML 파싱해서도 스트림 여부, 방제 얻어올 수 있음.
다만 이 경우엔 정식 API를 쓰는 게 아니니까 데이터가 제대로 안 들어올 수 있는 것에 특히 주의.

어쩔 수 없는 것 같긴 한데 썸네일을 얻는 URL이 이것저것 있으니 여러가지 시도해보게?

브라우저로 열면 알아서 방송으로 가긴 하는데 특히 모바일에서 알림이나 링크를 클릭하면 앱에서 제대로 안 열림.
방송 번호까지 포함된 링크를 사용해야 할 듯.

예를 들어 카테고리가 저챗에서 븨알챗으로 바뀌었는데 갑자기 다시 저챗으로 됐다가 다시 븨알챗으로 바뀜.
그래서 한번 보낼 알림을 세번 보내는데 실제로 그렇게 바꿨을 것 같진 않고 API 응답이 문제인 것 같음.
방제도 동일.
최근 갑자기 이러는 것 같음.

현재 디코, 트위터, 텔레그램에 썸네일이 올라가는데 각각 썸네일을 얻는 서버 위치가 다른 것인지 대부분 서로 다른 이미지로 나옴.
오래된 경우 3분 정도 이전 이미지가 나오는 듯.
서버 위치를 바꿔가며 테스트해봤지만 큰 개선은 없었음.
특정 플랫폼이 더 빠른 것도 아니었음.
어떻게 가장 최신의 이미지로 통일할 수 없을까.

Source code : functions/src/index.ts

곧 다른 방송 플랫폼 알림을 개발해야 하는데 다른건 서버에서 컨트롤 가능하지만 웹 푸시는 받는 쪽에서 컨트롤하는 부분(링크 등)이 꽤 있음.
알림 구현 전에 미리 플랫폼 구분값을 웹푸시 데이터에 넣어서 서버쪽 구현만 완료되면 바로 적용되도록 하자.

특히 폰이 그런 것 같은데 텔그는 즉시 받지만 웹푸시는 수분에서 십수분 지연되어 수신되는 경우가 있음.

파이어베이스의 하트비트 알고리즘 한계로 인한 것이라면 내쪽에서 해결은 힘들 듯.
혹시 몰라서 우선순위 높음으로 해봤으니 추후 확인.
TTL 문제일수도? TTL을 이 시간까지는 지연되어도 괜찮다는 의미로 쓰고 있다면?

왁타버스는 아프리카TV로 간다.
아프리카TV는 공식 API를 현재 개인 개발자가 사용할 수 없다.
비공식 API나 크롤링을 사용할 수 있겠으나 그 정도의 노력을 들일 가치가 있는가?
방송 알림은 속도를 좀 보긴 해야겠지만 앱이 지원할 것이고 방제, 카테고리 변경 알림은 이제 얻을 수 없겠지만 어차피 전부 켜놔서 필요성이 떨어짐. 왁스코드가 어떻게 해주지 않을까? 거긴 앞이랑 제휴도 맺을 수 있을 것 같은데..
따라서 서비스 종료를 고려할 예정.
이적하는 시점에 맞춰 파이어베이스 서버, 웹 사이트, 텔레그램, 디코 웹훅, 트위터 서비스를 종료하게 될 것.

언제부턴가 안 되는 듯.

이런 것조차 동일하게 표시못하는 웹 표준이란....
오페라, 사파리, 삼성 브라우저 등.

좀 어이가 없는데 send 함수에서 firebase internal error가 가끔 떠서 retry 로직 넣어놨더니 정작 메시지는 전부 전송되어 알림이 중복되는 현상 발생함.
그렇다고 retry 없에고 에러 무시하자니 진짜로 메시지 전송 안 되는 경우 있을까봐 더 지켜봐야 함.
알림 없는 것보단 여러번 오는 게 차라리 나을테니...
정 그러면 retry 횟수를 좀 줄이자.

4.14 기준 PC/모바일 크롬에서만 해봄.
모바일 크롬에선 Foreground 상태일때 알림 안 뜨는 문제 있음.
애플 쪽은 당연히 지원 안 될거고 파폭, 엣지, 삼성 브라우저 정도 확인 필요.

요즘 트위터에서도 꽤 방송(?)을 하신다. 알림에 추가하면 좋을 것 같긴 함.
트위터 알림의 경우엔 그냥 리트윗으로 끝내면 될 듯.
근데 API 정책이 어떨까.
요즘 트위터 상태가 메롱이라 무료 플랜으로 스페이스 상태 확인 얼마나 할 수 있을지 확인 필요.

사용하고 있는 라이브러리가 스트림 정보를 반환할 때 null이면 진행 중인 스트림이 없는 의미로 보라고 하는데 서버 오류가 있을 때에도 null을 반환한다.
실제로 뱅종이 되진 않았지만 서버가 불안정하여 시청자 수가 0으로 나온다거나 목록에 안 나온다거나 하는데 그럴 때 뱅종으로 인식해서 나중에 복구되면 뱅온 알림이 송출되어버림.
이걸 방지하기 위해 작업은 해두었는데 뱅종 무시 시간이 좀 짧은지 여전히 같은 현상 발생.
기존 25초에서 최대 3분까지 늘리는 걸 고려.
3분은 좀 길긴 하니 90초 정도로?

2023.04.15 새벽부터 뱅온 직후 썸네일이 안나옴. 나중에 방제나 카테고리 바뀌었을 땐 잘 나오는 거 보면 프로그램에 문제가 있는 건 아니고 트위치에서 썸네일 제공을 더 늦게 해주게 바뀐 듯? 이젠 썸네일도 가져가니 트위치야.

최근 그러는데 imgbb API 호출시 타임아웃이 발생하거나 응답 json이 잘못된 형식이거나 함.
그리고 정상적으로 업로드 되었음에도 디스코드에 해당 URL 제공하면 왜인지 종종 이미지 첨부가 안 됨.
업로드한지 얼마 안 되어서 디스코드가 이미지로 인식할 수 있을만한 데이터를 바로 제공하지 못하나?
그래서 imgbb 대신 Firebase Cloud Storage를 쓸까 싶음.
이미지 업로드하고 다운로드 URL 얻을 수 있음.
무료 제한이 넉넉하긴 한데 혹시 모르니 API 사용량 제한 걸고 오래된 이미지는 삭제하도록 해야함.

Hosting 배포는 쉽게 Action 지원해주면서 Functions는 왜 없을까.
이것저것 해봤지만 이해 부족으로 실패함.
로컬에서는 잘 올라가니 천천히 진행.

getStream API가 null을 반환하면 방송 상태가 아니란 의미로 쓰이는데 이게 뱅종이 아님에도 종종 null을 반환함.
그래서 다시 복구되면 뱅온 알림이 송출되어버림.