-
radiko 녹음 스크립트 수정 과정 기록IT,컴퓨터/서비스,웹,소프트웨어 2020. 12. 10. 10:30하단 광고는 티스토리가 임의 삽입하여 노출되고 있습니다728x90
올해 2월에 아래와 같은 제목의 글을 적은 적이 있습니다.
radiko, 초! A&G 녹음환경 구성 및 Synology NAS 파일전송 자동화
이 환경은 지금까지도 아주 유용하게 쓰고 있습니다.
이거 하느라 늘은 관심으로 이런저런 환경을 구축해 두니, 필요할때 적절히 써먹고 아주 좋네요.
나중에 해외망 속도가 나아지는 유선통신망 환경이 되더라도 계속 쓰게 되지 싶습니다.
그러던 지난 주말, 일요일 새벽 사이에 녹음/녹화된 파일이 옮겨진 뒤 오는 '작업 완료' 메일을 보고 NAS로 들어가보니
radiko 에서 녹음되는 파일들만 빠져있더군요.
트위터 검색해보니 12/3일자 앱 업데이트 후 API가 약간 변경되었는지 녹음에 실패했다는 트윗이 꽤 보였습니다.
그래서 제 평화로운 라디오 라이프를 위해(?) 쓰던 스크립트를 분석하고 radiko 서비스 PC 홈페이지 동작을 기반으로 수정한 내용을 기록차 올립니다.
구체적으로 주저리 쓰진 않을거고(사실 정식 API는 아닌걸로 알고 있음) 그냥 '이렇게 서비스 파악했고 이런걸 수정했다' 정도 내용으로만.
과연 어느 부분에서 문제가 생겼을까요?
..음, 일단 길어져서 덮어둡니다.
더보기1. 스크립트를 참고하여 서비스 확인
확인하기에 앞서, 제가 한 작업에서의 준비물은 아래와 같습니다.
-일본IP 획득이 가능한 VPN 서비스
ExpressVPN 등의 유료 VPN은 가끔 일본지역으로 접속해도 서비스 가능으로 뜨지 않습니다. 참고하시길.
-radiko 계정
유료 혹은 무료 아무거나. IP 인식지역과 동일한 권역의 방송을 녹음할 예정이라면 없어도 됩니다
(도쿄지역으로 인식되면 도쿄지역 라디오는 무료청취 가능)
-VPN서비스를 사용한 상태에서 접속할 수 있는 웹브라우저
이걸로 radiko PC 홈페이지에 접속해서 이것저것 들여다 볼 겁니다.
개인적으론 크롬 디버그 도구가 좋아서 업무에서도 이걸 쓰기 때문에 여기서도 크롬 디버그 도구를 썼습니다.
-일본IP 획득이 가능한 리눅스 서버
어차피 최종적으로 녹음작업은 리눅스 서버에서 돌리는거라 그거랑 같은(혹은 비슷한) 환경에서 테스트 및 확인했습니다.
저는 CentOS 7.9 사용중이라 이 기준으로 작성됐습니다...만, 돌리는 docker 환경은 ubuntu라 보시는데 크게 영향은 없을겁니다.
...좀 까다롭죠.
제 경우는 일본의 클라우드 서비스(conoha)에서 리눅스 가상서버를 임대하고 있고, 여기에 VPN, 녹음환경 등이 구축되어 있습니다.
그래서 주 테스트는 이 서버에 접속하여 진행하고, 동작이 예상처럼 안되면 VPN붙은 윈도우 데스크톱에서 radiko 홈페이지 접속해 디버그 모드로 동작을 파악해가며 작업을 진행했습니다.
사실 단순 관심이 아니라 실제 녹음을 진행하시는 분이라면 위 중에서 최소 두개는 사용이 가능하지 않을까 싶지만요.
그러면 제가 한 대로 따라가 봅시다.
우선, 수정 전 radiko 녹음 스크립트는 아래와 같았습니다.
지난달 말까지는 radiko가 플래시를 사용한 player를 로딩해와서 음성을 재생했는데,
꾸준히 웹 환경에서 도태되어 왔고 이제는 지원까지 단계적으로 중단되고 있다 보니 radiko 측도 지난달 말 플래시를 완전히 걷어냈습니다.
하지만 구버전 녹음 스크립트에서는 아직 플래시 player를 가져와 이 플래시를 파싱해 녹음 URL을 뽑아내 녹음합니다.
그 외적으로는 IP에서 인식되는 지역 이외 지역 라디오도 청취 가능한 radiko 프리미엄 유저 체크를 위해
스크립트 실행시 파라메터로 계정정보가 입력되면 로그인 URL을 호출해 쿠키를 만들고, 이 쿠키를 사용해 여기저기 인증 URL을 호출해 인증Key 값을 받아 처리하는 부분도 있군요.
아무튼 이 스크립트를 따라 동작을 파악해 봅니다.
이런식으로 스크립트 안에 있는 명령어를 가져오고, 예상되는 변수의 입력값을 채워 요청을 보내보는 식으로 테스트를 진행했습니다.
그러다가 문제가 생기거나 제가 예상한 대로(=스크립트 제작자가 의도한 대로) 동작하지 않으면
이렇게 PC 홈페이지에서 그 부분을 동작시켜보면서 어떤 method와 HTTP Header, 어떤 파라메터를 사용하는지 확인한 뒤 스크립트를 수정하거나 그랬습니다.
아, 원 스크립트에는 wget으로 호출하는데, 개인적으론 curl이 더 편해서 이쪽을 사용했습니다.
옵션명만 좀 다를 뿐이지 전체적인 동작에는 차이가 없습니다.
그리고 결국 아래의 두 URL이 변경되었다는 것을 알게 되었습니다.
https://radiko.jp/v2/api/auth1_fms
https://radiko.jp/v2/api/auth2_fms
여기서 나오는 인증Key를 녹음 스트림 URL 호출할때 헤더에 설정해야 하는데, 위 인증 URL에서 404 에러가 났으니 이후 과정을 하나도 못했겠죠.
다행히 먼저 적은 구글 크롬 디버그 도구로 변경된 URL을 알아낼 수 있었습니다. 아래 두 URL입니다.
https://radiko.jp/v2/api/auth1
https://radiko.jp/v2/api/auth2
어느 URL이 기존 URL과 매칭되는지는 쉽게 짐작이 되실 겁니다. 끝에서 _fms가 지워졌을 뿐이죠?
이제 이 부분을 바꾸면 스크립트는 다시 녹음 작업을 할 수 있게 될 겁니다.
...이제 문제가 끝나고 저는 손을 떼게 될까요?
2. 아직도 플래시를 사용해서 녹음하고 있었다니
하지만, 다 좋은데 먼저 언급했듯 아직도 플래시로 만들어진 player에서 스트림 URL을 추출하고 있었습니다.
때문에 스크립트 사용을 위해선 swftool 과 rtmpdump 라는 두 오픈소스가 추가로 필요했고,
먼저 언급했듯 플래시는 현재 웹, 운영체제 모두에서 퇴출 막바지 단계입니다.
이를 그냥 두면 언젠가 이른 시일 내에 또 손을 댈 일이 생길 것이라 예상했습니다.
그래서 지난달 말에 플래시를 걷어낸 현재의 radiko PC용 홈페이지를 보고 전체적인 수정을 하기로 합니다.
소위 말하는 HLS(HTTP Live Streaming) 녹음에 대응하기로 한 거죠.
다행히 이 HLS는 ffmpeg라는 오픈소스를 쓰면 아주 쉽게 녹음할 수 있습니다.
기존 스크립트에서도 rtmpdump로 녹음된 flv를 좀 더 다루기 쉬운 파일로 변환하기 위해 사용했기에
이를 중심으로 사용하도록 수정하면 변경 자체는 어렵지 않을것 같더군요.
이번엔 제가 수정한 가장 큰 부분을 하나 떼어 오고, 최종적으로 바꾼 전체 스크립트를 올려두겠습니다.
Git 레포지토리에도 올라가 있으니 비교하셔도 재밌을 겁니다. 재밌을 분이라면..(?)
가장 크게, 이 부분이 추가되었습니다.
보통 HLS 스트림은 m3u8 확장자 인덱스 파일 URL만 알 수 있으면 ffmpeg의 input 파라메터로 주고 녹음을 진행할 수 있는데,
radiko의 경우는 이 m3u8 뒤에 ? 로 추가되는 GET 방식 파라메터가 몇개 더 붙지 않으면 호출이 실패하는 구조였습니다. (Header의 인증Key는 이전과 동일하게 필수)
좀 찾아보니, station_id는 대문자 방송국 코드, l은 무조건 15로 넘어가고 lsid 는 임의로 생성해도 문제가 없었는데
type 이라는 변수가 골치더군요.
몇번 URL 호출이 실패하길래 먼저 만들어둔 분들의 스크립트를 참고하니, full.xml 이라는 radiko 전체 방송국 정보를 담고있는 XML 파일에 방송국마다 값을 가지고 있더군요. (areafree 태그 영역)
그래서 매번 녹화때마다 전체 방송국 정보를 가져오고, 이 XML 파일을 xmllint 로 파싱해서 거기에 있는 방송국별 areafree 정보를 가져와 URL 호출시 반영하는 로직이 필요했습니다.
이 부분이 그 기능을 위해 추가됐네요.
xmllint 사용이 익숙하지 않아서, 방송국 ID로 찾은 <station></station> 태그 하위 엘리먼트 값 가져오는 xPath 짜는데 조금 고전했던 기억이 있습니다;
그래도 이후로 잘 동작하니 안심이 됩니다.
제 경우는 프리미엄 기능 중 하나인 타지역 방송 녹화도 진행하는지라, 그쪽 테스트도 잘 되는걸 확인했고.
..음, 그 외엔 rtmpdump 대신 ffmpeg로 녹음 툴을 변경하고, wget으로 진행하던 API 호출을 curl로 변경한거 정도가 변경점 같네요.
stream URL을 가지고 있는 방송국ID XML 파일에서 URL을 가져오는 방식도 살짝 변경했고,
기존에 wget 사용시 설정한 HTTP Header 중 PC 홈페이지를 참고해 현재 사용하지 않거나 누락된 것을 추가하고 제거하기도 했구요.
아무튼 그래서 최종 수정된 스크립트는 아래와 같습니다.
이렇게만 올리면 당연히 눈에 잘 안들어오실거라, 더 궁금한 분이 계시다면 Git 레포지토리의 History를 참고하시라고 링크도 남겨둡니다.
이번 글은 여기까지.
사실 엄밀히 말하면 'PC 홈페이지를 이용하는것 처럼 서비스를 속여서' 녹음을 하는거라 글을 적을까 조금 고민했는데,
상세한 호출 스펙을 나열하는 대신 제가 서비스를 소위 뜯어본 '방식'만을 대략적으로 적는 방향으로 바꾸고 어쨌든 글은 정리했습니다.
이것도 약간 계기가 있는데, 예전에 響(히비키 라디오 스테이션)에서 방송 다운로드 받아야 할 일이 있었을 때,
관련 내용을 검색하다가 아래의 일본분 분석글을 보고 도움을 받은 적이 있기 때문이었습니다.
Python3でradikoと超A&Gと音泉と響を自動検索・録音するソフトを作った
그래서 저도 나중에 '이런 글 한번 적어봐야겠다' 생각하고 있었는데, 마침 어제 수정한다고 난리통을 겪고 나니 많이 눈에 보여서 겸사겸사 정리하게 된겁니다.
혹시나 궁금하셨던 분들에게는 도움 되셨길 빕니다.
근데, 솔직히 이렇게까지 한 서비스를 분석해본 적이 없어서... 생각보다 재미있고 인상적이었네요.
다음에도 이런 기회가 있으면 좋겠습니다. 시간이 있고 관심이 있다면 언제든 생기겠지만요.
..그럼 주말 전후로 또 느긋하게 글 들고 오겠습니다.
오락가락하는 추위 조심하시고 남은 한주 건강히 보내시길.
'IT,컴퓨터 > 서비스,웹,소프트웨어' 카테고리의 다른 글
ffmpeg 연결 재시도 옵션 설정(라디오 녹음, 녹화시) (0) 2021.08.08 conoha VPS 납부방식 전환 및 서버 업그레이드 (0) 2021.05.13 ffmpeg로 녹화영상 압축하기 - 2. 일부 옵션별 영상스펙 비교 & 결론 (0) 2020.09.13 conoha 네트워크 속도제한에 걸리다 (0) 2020.09.08