[Bug]:运行结果错误 #841
Comments
|
今天更新的版本应该是有代码问题，有某个设定更改了必定触发❌ Write channel to file failed: list index out of range。 |
|
不好意思 又研究了一下 应该可能不是代码问题，好像是最近一次更新的订阅源的问题。 我再尝试一下 等下会在下面回复尝试结果。 |
|
好吧 最后尝试了一下 还是不太清楚到底是哪里出了问题。。。我放弃了，等后续看有没有人遇到类似问题。 |
|
大大好，稍早我尝试用Github Action 自行运行了一次，订阅源跟这个git 完全一致，只做了设定config上的更改。然后出现了一样的错误。 错误和我自己的Docker也是一样 大大如果有时间，也可以到我的git上面看一下action 跑的结果。希望能修正这个问题。 然后就是下午我在discussion说的测速的问题。我认为当前的代码应该存在部分问题，好像只会获取部分订阅源的直播源然后进行测速，其他的直播源就不会成功测速。（不会成功测速的直播源有确定能顺畅运行的，但是IPTV-API当前的代码不会使用相关直播源） |
|
我查看了你的工作流运行结果，近两次似乎都是成功没有问题的。 |
近两次是用特地回退的旧版本branch-回退到前几天的版本跑的（feat:docker proxy -Commit aed9b91），一旦用了master的代码 就是会出现错误，我中午跑了2次都一样，不太清楚问题出在哪里。 （您可以查看 Update schedule #1 UPDATE最后是显示错误的） 您说的 “相同域名的接口”的部分，我印象中好像是没有出现的，测速列表内没有出现我所谓的速度快的直播源。 关于接口测速-能不能加个设定，可以对全部直播源进行测速。因为海外几乎有98%的直播源是肯定不能用的，如果随机对直播源测速，那要刷好多次才能出部分可以用的结果，而且隔12小时可能又没有那些直播源了。 分辨率检测应该还是有点问题的，因为有些直播源速度很快，然后检测会出现没有解析率，然后实际直播源是1080P的。 |
|
1.关于写入文件报错问题，我有空会去复现解决。 |
不清楚是不是我的网络问题，我得出的结果有85%都是得不出解析率的。 Name: CCTV-1, URL: http://z.b.bkpcp.top/m.php?id=cctv1$订阅源, Date: None, Delay: 200 ms, Speed: 1.80 M/s, Resolution: None Name: CCTV-1, URL: https://www.freetv.top/migu/608807420.m3u8?migutoken=5b04cf0d91179ab2d3d71703f0a8bc3d32dd02f7d8fb55ee70e05c216b8a9d1a73d911fbde798459fb66d94934157c996f8306c0dd37917775f2ed73dcc22cf84b25ca500bff5c636ff48d6344$订阅源, Date: None, Delay: 267 ms, Speed: 1.41 M/s, Resolution: None Name: CCTV-1, URL: http://cc-ynbit-wszhibo.ifengli.com:2000/live/cctv-1hd/2500.m3u8?innersid=1587240374177179388$订阅源, Date: None, Delay: 13 ms, Speed: 44.80 M/s, Resolution: None Name: CCTV-1, URL: http://182.92.109.190:1668/72/72.php?id=cctv1$订阅源, Date: None, Delay: 200 ms, Speed: 1.63 M/s, Resolution: None Name: CCTV-1, URL: http://182.92.109.190:1668/migu720/migu720.php?id=cctv1$订阅源, Date: None, Delay: 200 ms, Speed: 1.63 M/s, Resolution: None Name: CCTV-2, URL: http://z.b.bkpcp.top/m.php?id=cctv2$订阅源, Date: None, Delay: 200 ms, Speed: 1.80 M/s, Resolution: None Name: 万州综合, URL: http://wanzhoulive.cbg.cn:8017/iTXwrGs/800/live.m3u8$订阅源, Date: None, Delay: 59 ms, Speed: 5.15 M/s, Resolution: None Name: 凤凰中文, URL: https://k44991.kylintv.tv/live/pxna_iphone.m3u8$订阅源, Date: None, Delay: 567 ms, Speed: 6.23 M/s, Resolution: None Name: CHC家庭影院, URL: http://eastscreen.tv/ooooo.php?id=chcjt$订阅源, Date: None, Delay: 231 ms, Speed: 7.17 M/s, Resolution: None Name: 音乐之声, URL: http://ngcdn003.cnr.cn/live/yyzs/index.m3u8$订阅源, Date: None, Delay: 17 ms, Speed: 8.24 M/s, Resolution: None Name: 湖南卫视, URL: http://antvlive.ab5c6921.cdnviet.com/antv/playlist.m3u8$订阅源, Date: None, Delay: 71 ms, Speed: 10.15 M/s, Resolution: None 恰巧这些还都是我最终测速结果内速度快的直播源，且还是应该进到最终列表内的（但因为检测不到分辨率，没列入最终m3u内），有少量速度慢的反而能测出分辨率。
额外补充： |
|
我依次测试了你提供的这些接口，发现只有一个接口是有延迟、速率却没有获取分辨率的情况，其余有效的接口都能获取到分辨率。我猜测大概率是因为引用了同域名接口的结果导致的情况。 |
|
好的，我研究研究
…---原始邮件---
发件人: ***@***.***>
发送时间: 2025年1月20日(周一) 中午11:39
收件人: ***@***.***>;
抄送: ***@***.***>;
主题: Re: [Guovin/iptv-api] [Bug]:运行结果错误 (Issue #841)
我依次测试了你提供的这些接口，发现只有一个接口是有延迟、速率却没有获取分辨率的情况，其余有效的接口都能获取到分辨率。我猜测大概率是因为引用了同域名接口的结果导致的情况。
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
之前我没学过代码，我研究研究，挺有意思的
…---原始邮件---
发件人: ***@***.***>
发送时间: 2025年1月20日(周一) 中午11:39
收件人: ***@***.***>;
抄送: ***@***.***>;
主题: Re: [Guovin/iptv-api] [Bug]:运行结果错误 (Issue #841)
我依次测试了你提供的这些接口，发现只有一个接口是有延迟、速率却没有获取分辨率的情况，其余有效的接口都能获取到分辨率。我猜测大概率是因为引用了同域名接口的结果导致的情况。
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
1.已修复文件写入问题； |
|
好的 感谢回复与更新 稍后我重建docker，再测试看看。 |
|
不好意思 那个重复测速好像没正常运行。我看我的测速列表内同一个域名 全部都出现一样的速度和延迟。 补充： Name: CCTV-1, URL: https://www.freetv.top/migu/608807420.m3u8?migutoken=5b04cf0d91179ab2d3d71703f0a8bc3d32dd02f7d8fb55ee70e05c216b8a9d1a73d911fbde798459fb66d94934157c996f8306c0dd37917775f2ed73dcc22cf84b25ca500bff5c636ff48d6344$订阅源, Date: None, Delay: 730 ms, Speed: 0.95 M/s, Resolution: None 回退的旧版本： Name: CCTV-1, URL: https://www.freetv.top/migu/608807420.m3u8?migutoken=5b04cf0d91179ab2d3d71703f0a8bc3d32dd02f7d8fb55ee70e05c216b8a9d1a73d911fbde798459fb66d94934157c996f8306c0dd37917775f2ed73dcc22cf84b25ca500bff5c636ff48d6344$订阅源, Date: None, Delay: 220 ms, Speed: 1.61 M/s, Resolution: None 两个版本测速的时间非常接近，大概误差在15分钟内。 但好消息是分辨率有比较高的几率读出来了。 我现在在单独重跑一次新版本看看。 |
|
跑了第二次 还是得不出结果。 第二个 跑第二次还是得不出解析率，自己打开的速度确实是快的 能跑到2m，不缓冲。 现在尝试关闭 分辨率判定，再跑一次看。 |
|
你似乎误解了，sort_duplicate_limit=3是指3个域名相同的接口都执行测速等操作，结果取平均值，所以它们的结果是一样的，都是平均值结果，属于正确情况。 |
|
好的 不好意思。 我提供一下 新旧版本的log |
|
这是因为你设定的最小速率太高了，很多接口并不满足这个要求，同时你又把补偿关了，所以结果为空。 |
Don't skip these steps | 不要跳过这些步骤
Occurrence environment | 触发环境
Bug description | 具体描述
今天新下的Docker image 重建后运行第一次正常，但重启第二次开始运行 会出现错误。
❌ Write channel to file failed: list index out of range
✅ M3U result file generated at: /iptv-api/output/result.m3u
🥳 Update completed! Total time spent: 23:21. Please check the output/result.txt file!
Error log | 报错日志
Config
[Settings]
open_driver = False
open_empty_category = False
open_filter_resolution = True
open_filter_speed = True
open_hotel = False
open_hotel_foodie = True
open_hotel_fofa = True
open_keep_all = False
open_local = True
open_m3u_result = True
open_multicast = False
open_multicast_foodie = True
open_multicast_fofa = True
open_online_search = False
open_proxy = False
open_request = False
open_service = True
open_sort = True
open_subscribe = True
open_supply = False
open_update = True
open_update_time = True
open_url_info = False
open_use_cache = True
open_history = True
app_port = 8000
final_file = output/result.txt
hotel_num = 10
hotel_page_num = 1
hotel_region_list = 全部
ipv4_num = 5
ipv6_num = 5
ipv6_support = True
ipv_type = 全部
ipv_type_prefer = 自动
local_file = config/local.txt
local_num = 10
min_resolution = 1920x1080
min_speed = 0.5
multicast_num = 10
multicast_page_num = 1
multicast_region_list = 全部
online_search_num = 0
online_search_page_num = 1
origin_type_prefer =
recent_days = 30
request_timeout = 10
sort_timeout = 10
source_file = config/demo.txt
subscribe_num = 10
time_zone = Asia/Shanghai
urls_limit = 6
update_time_position = top
The text was updated successfully, but these errors were encountered: