Heterojen akış uç noktası koleksiyonlarının yeniden kullanılabilir hâle getirilmesi için medya türü duyarlı asenkron bir çerçeve

Abstract

Kullanıcıların sürdürdüğü İnternet radyosu ve IPTV benzeri oynatma listeleri çoğu zaman erişilemeyen, yinelenen, yönlendirilmiş, hatalı biçimli ya da medya içermeyen uç noktalar barındırır. Bu makale, oynatma listesi düzeyinde medya türü duyarlı doğrulama, URL dönüşümü, geçersiz kayıtların çıkarılması ve doğrulanmış alternatif seçimi yoluyla heterojen akış uç noktası koleksiyonlarını yeniden kullanılabilir hâle getiren, yeniden üretilebilir ve köken bilgisini (provenance) koruyan bir Python çerçevesini değerlendirmektedir. Çerçeve TXT, M3U/M3U8, boru imiyle ayrılmış ve AIMPPL4 girdilerini ayrıştırmakta, istasyon-URL çiftlerini normalleştirmekte ve ardından HEAD 405/501 yanıtı sonrasında gövde okuması bir baytla sınırlandırılmış GET yedeğine sahip asenkron HTTP HEAD yoklamasını uygulamaktadır. Daha sonra dönüştürülen URL'leri yeniden doğrulamakta, istasyon başına bir doğrulanmış alternatif seçmekte ve makinece okunabilir kanıt dışa aktarmaktadır. Birincil bulut ortamında sabit 400 uç noktalık örneklem üzerindeki üç yinelemede, 50 eşzamanlılık sınırı ortalama doğrulama süresini 211,6 saniyeden 6,3 saniyeye indirmiş ve 33,6 kat hızlanma sağlamıştır. İkinci bir ortamdaki bağımsız yineleme aynı zamanlama yönünü göstermiştir. Ayrı bir tam korpus değerlendirmesi 1.858 benzersiz çiftin tamamını 31,14 saniyede işlemiş, 485 uç noktayı doğrulamış ve 372 istasyon için uç nokta seçmiştir. Dört yapılandırmalı betimsel kabul/onarım analizinde, yalnızca durum denetimli ve onarımsız ayar ortalama 25,6 medya dışı 2xx yanıtını kabul ederken medya türü denetimli ve onarımlı ayar 115,8 medya uyumlu uç noktayı kabul etmiş ve 29,3 uç noktayı kurtarmıştır. Örneklenen kod çözücü tabakaları içinde, kurtarılan 19 benzersiz URL'nin tamamı kısa bağımsız medya yoklamasını geçmiş, yalnızca durum denetimli 18 benzersiz medya dışı URL'nin hiçbiri geçmemiş; ancak doğrulayıcının reddettiği 20 URL'den üçü de bu yoklamayı geçmiştir. Bu sonuçlar, belirtilen deney koşulları altında uç nokta koleksiyonlarının zaman sınırlı biçimde yeniden kullanılabilir hâle getirilmesini nitelemekte; uzak hizmetlerin geri kazanımını, sürekli oynatmayı veya deneyim kalitesini ortaya koymamaktadır.

Keywords

• İnternet radyosu
• IPTV oynatma listesi
• Akış uç noktası yeniden kullanılabilirliği
• Asenkron G/Ç
• Medya türü doğrulama

Ethical Statement

Bu çalışma yalnızca teknik çalma listesi dosyalarını ve sınırlandırılmış HTTP uç nokta üstverilerini kullandığı; insan katılımcı, hayvan, müdahale veya kişisel veri içermediği için etik kurul onayı gerektirmemiştir. Yoklama trafiğini sınırlandırmak amacıyla uygulamada HEAD öncelikli istekler, istemcinin okuduğu yanıt gövdesinden en fazla bir baytla sınırlandırılmış bir geri dönüş mekanizması, 65.536 baytla sınırlandırılmış GET varyantları ve istek başına zaman aşımı süreleri kullanılmıştır. Eşzamanlılık penceresi ana makineye özgü değil, istemci genelindedir. Bu nedenle, uç noktaların belirli ana makinelerde yoğunlaştığı listeler üzerindeki sorumlu yeniden çalıştırmalarda ana makine düzeyinde hız veya eşzamanlılık sınırları uygulanmalı ve ilgili hizmet politikalarına uyulmalıdır.

A media-type-aware asynchronous framework for restoring heterogeneous stream endpoint collections

Abstract

User-maintained Internet radio and IPTV-like playlists often contain unavailable, duplicate, redirected, malformed, or non-media endpoints. This article evaluates a reproducible, provenance-preserving Python framework for restoring heterogeneous stream endpoint collections through playlist-level media-type-aware validation, URL transformation, invalid-entry removal, and verified alternative selection. The framework parses TXT, M3U/M3U8, pipe-delimited, and AIMPPL4 inputs and normalizes station–URL pairs before applying asynchronous HTTP HEAD probing with a GET fallback whose response-body read is capped at one byte after HEAD 405/501. It then revalidates transformed URLs, selects one validated alternative per station, and exports machine-readable evidence. Across three repetitions on a fixed 400-endpoint sample in the primary cloud environment, a concurrency limit of 50 reduced mean validation time from 211.6 to 6.3 seconds, a 33.6-fold speedup. An independent repetition in a second environment showed the same timing direction. A separate full-corpus evaluation processed all 1,858 unique pairs in 31.14 seconds, validated 485 endpoints, and selected endpoints for 372 stations. In a four-configuration descriptive acceptance/repair analysis, the status-only/no-repair setting accepted 25.6 non-media 2xx responses on average, whereas the media-type/repair setting accepted 115.8 media-compliant endpoints and rescued 29.3. Within the sampled decoder strata, all 19 unique rescued URLs passed a short independent media probe and none of the 18 unique status-only non-media URLs did, although three of 20 validator-rejected URLs also passed. These results characterize time-bounded restoration of endpoint collections under the specified experimental conditions and do not establish recovery of remote services, sustained playback, or quality of experience.

Keywords

• Internet radio
• IPTV playlist
• stream endpoint restoration
• asynchronous I/O
• media-type validation

Ethical Statement

Ethics committee approval was not required for this study because it used technical playlist files and bounded HTTP endpoint metadata and involved no human participants, animals, interventions, or personal data. To limit probe traffic, the implementation used HEAD-primary requests, a fallback capped at one client-read response-body byte, GET variants capped at 65,536 bytes, and per-request timeouts. The concurrency window was client-wide rather than host-specific. Responsible reruns on host-concentrated lists should therefore apply host-level pacing or concurrency limits and comply with applicable service policies.

References

1. [1] W3C, “node-linkchecker: Detect Broken Links and Broken Fragments.” GitHub repository, 2019. Available: https://github.com/w3c/node-linkchecker
2. [2] peterpt and contributors, “IPTV-CHECK: M3U Playlist Online/Offline Link Checker.” GitHub repository, 2025. Available: https://github.com/peterpt/IPTV-CHECK
3. [3] freearhey and contributors, “iptv-checker: Node.js CLI Tool for Checking Links in IPTV Playlists.” GitHub repository, 2026. Available: https://github.com/freearhey/iptv-checker
4. [4] Z. Bar-Yossef, A. Z. Broder, R. Kumar, and A. Tomkins, “Sic Transit Gloria Telae: Towards an Understanding of the Web’s Decay,” in Proceedings of the 13th International Conference on World Wide Web (WWW), ACM, 2004, pp. 328–337. doi: 10.1145/988672.988716.
5. [5] T. Xiao et al., “18 Million Links in Commit Messages: Purpose, Evolution, and Decay,” Empirical Software Engineering, vol. 28, no. 4, p. 91, 2023, doi: 10.1007/s10664-023-10325-8.
6. [6] J. Liu et al., “Broken External Links on Stack Overflow,” IEEE Transactions on Software Engineering, vol. 48, no. 9, pp. 3242–3267, 2022, doi: 10.1109/TSE.2021.3086494.
7. [7] C. López, D. Morato, E. Magaña, and M. Izal, “Validation of HTTP Response Time From Network Traffic as an Alternative to Web Browser Instrumentation,” IEEE Transactions on Network and Service Management, vol. 19, no. 2, pp. 976–990, 2022, doi: 10.1109/TNSM.2021.3121468.
8. [8] Y. Li, X. Zhang, C. Cui, S. Wang, and S. Ma, “Fleet: Improving Quality of Experience for Low-Latency Live Video Streaming,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 33, no. 9, pp. 5242–5256, 2023, doi: 10.1109/TCSVT.2023.3243901.

9. [9] J. A. Hernandez and M. Colom, “Reproducible Research Policies and Software/Data Management in Scientific Computing Journals: A Survey, Discussion, and Perspectives,” Frontiers in Computer Science, vol. 6, p. 1491823, 2025, doi: 10.3389/fcomp.2024.1491823.
10. [10] C. Guevara-Vega, B. Bernárdez, M. Cruz, A. Durán, A. Ruiz-Cortés, and M. Solari, “Research Artifacts for Human-Oriented Experiments in Software Engineering: An ACM Badges-Driven Structure Proposal,” Journal of Systems and Software, vol. 218, p. 112187, 2024, doi: 10.1016/j.jss.2024.112187.
11. [11] D. Sondhi, A. Sharma, and D. Saha, “Refining Tests through API Response Evaluation,” in Proceedings of the 19th Innovations in Software Engineering Conference, ACM, 2026, pp. 1–11. doi: 10.1145/3796563.3796607.
12. [12] L. Liu et al., “Camel: Frame-Level Bandwidth Estimation for Low-Latency Live Streaming under Video Bitrate Undershooting,” in Proceedings of the ACM Web Conference 2026, ACM, 2026, pp. 5557–5567. doi: 10.1145/3774904.3792535.
13. [13] R. T. Fielding, M. Nottingham, and J. Reschke, “HTTP Semantics,” Internet Engineering Task Force, RFC 9110, 2022. doi: 10.17487/RFC9110.
14. [14] R. Pantos and W. May, “HTTP Live Streaming,” Internet Engineering Task Force, RFC 8216, 2017. doi: 10.17487/RFC8216.
15. [15] T. Stockhammer, “Dynamic Adaptive Streaming over HTTP,” in Proceedings of the Second Annual ACM Conference on Multimedia Systems, ACM, 2011, pp. 133–144. doi: 10.1145/1943552.1943572.
16. [16] M. Seufert, S. Egger, M. Slanina, T. Zinner, T. Hoßfeld, and P. Tran-Gia, “A Survey on Quality of Experience of HTTP Adaptive Streaming,” IEEE Communications Surveys & Tutorials, vol. 17, no. 1, pp. 469–492, 2015, doi: 10.1109/COMST.2014.2360940.
17. [17] A. A. Barakabitze et al., “QoE Management of Multimedia Streaming Services in Future Networks: A Tutorial and Survey,” IEEE Communications Surveys & Tutorials, vol. 22, no. 1, pp. 526–565, 2020, doi: 10.1109/COMST.2019.2958784.
18. [18] A. Bentaleb, B. Taani, A. C. Begen, C. Timmerer, and R. Zimmermann, “A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP,” IEEE Communications Surveys & Tutorials, vol. 21, no. 1, pp. 562–585, 2019, doi: 10.1109/COMST.2018.2862938.
19. [19] K. Chen, B. Wang, W. Wang, X. Li, and F. Ren, “DeeProphet: Improving HTTP Adaptive Streaming for Low Latency Live Video by Meticulous Bandwidth Prediction,” in Proceedings of the ACM Web Conference 2023, ACM, 2023, pp. 2991–3001. doi: 10.1145/3543507.3583364.
20. [20] M. Seufert, R. Schatz, N. Wehner, and P. Casas, “QUICker or Not? An Empirical Analysis of QUIC vs TCP for Video Streaming QoE Provisioning,” in 2019 22nd Conference on Innovation in Clouds, Internet and Networks and Workshops, IEEE, 2019, pp. 7–12. doi: 10.1109/ICIN.2019.8685913.
21. [21] D. Spinellis, “The Decay and Failures of Web References,” Communications of the ACM, vol. 46, no. 1, pp. 71–77, 2003, doi: 10.1145/602421.602422.
22. [22] M. Klein et al., “Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot,” PLOS ONE, vol. 9, no. 12, p. e115253, 2014, doi: 10.1371/journal.pone.0115253.
23. [23] A. Nyayachavadi, J. Zhu, and H. V. Madhyastha, “Characterizing ‘Permanently Dead’ Links on Wikipedia,” in Proceedings of the 22nd ACM Internet Measurement Conference (IMC), ACM, 2022, pp. 388–394. doi: 10.1145/3517745.3561451.
24. [24] Radio Browser community, “radio-browser.info: Community Radio Station Index and API.” Online service documentation, 2026. Available: https://docs.radio-browser.info
25. [25] A. Golmohammadi, M. Zhang, and A. Arcuri, “Testing RESTful APIs: A Survey,” ACM Transactions on Software Engineering and Methodology, vol. 33, no. 1, pp. 1–41, 2024, doi: 10.1145/3617175.
26. [26] Python Software Foundation, “asyncio: Asynchronous I/O.” 2026. Available: https://docs.python.org/3/library/asyncio.html
27. [27] aiohttp contributors, “aiohttp Client Quickstart.” 2026. Available: https://docs.aiohttp.org/en/stable/client_quickstart.html
28. [28] G. K. Sandve, A. Nekrutenko, J. Taylor, and E. Hovig, “Ten Simple Rules for Reproducible Computational Research,” PLOS Computational Biology, vol. 9, no. 10, p. e1003285, 2013, doi: 10.1371/journal.pcbi.1003285.
29. [29] N. Freed and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” Internet Engineering Task Force, RFC 2046, 1996. doi: 10.17487/RFC2046.