dialdown 0 Posted February 23 Share Posted February 23 No trailers play. emby 4.8.1.0 If I grab the command line from the emby log (and remove emby specific command line options like timing etc, and run that against the latest ffmpeg from ffmpeg, it creates the proper .ts file. Windows 7, but as the last time I checked right after the 4.8 upgrade you were still saying windows vista as minimum, which windows 7 meets. ffmpeg-transcode-c8a8f430-2934-4550-b321-997db13bb20d_1.txt Link to comment Share on other sites More sharing options...
Abobader 2947 Posted February 23 Share Posted February 23 Hello dialdown, ** This is an auto reply ** Please wait for someone from staff support or our members to reply to you. It's recommended to provide more info, as it explain in this thread: Thank you. Emby Team Link to comment Share on other sites More sharing options...
Luke 37099 Posted February 23 Share Posted February 23 Hi there, please attach the main emby server log as well. thanks. Link to comment Share on other sites More sharing options...
dialdown 0 Posted February 23 Author Share Posted February 23 (edited) I did a lot of troubleshooting, such as replacing the ffmpeg in the system directory to see what other versions behaved, which wouldn't run as I found out because your heavily patched ffmpeg add commandline options that stock ffmpeg doesn't tolerate, so you may see things in that log that will likely distract you and lead to false conclusions. But in the previously attached ffmpeg error log, that was run from your ffmpeg which is borne out by the banner ffmpeg version 5.1-emby_2023_06_25 Copyright (c) 2000-2022 the FFmpeg developers and softworkz for Emby LLC I also ran your ffmpeg from the command line so I could see the output error directly and it failed with creating security context, which is a SSL/TLS error. embyserver.txt ffmpeg-transcode-e0334de0-cff6-4265-86ec-a0f01dc3293a_1.txt ffmpeg-transcode-de28bb9f-94fa-4a8a-9c7c-7fc063b7b2a5_1.txt ffmpeg-transcode-9d5c0f0a-10ec-43e7-9835-2d2159e92546_1.txt Edited February 23 by dialdown Link to comment Share on other sites More sharing options...
Luke 37099 Posted February 24 Share Posted February 24 So if you look at this: https://github.com/mpv-player/mpv/issues/4605#issuecomment-315417601 Looks like an issue with the remote host's certificate chain. I suppose we could always add an option to use --tls-verify=no Where did these trailers come from? Link to comment Share on other sites More sharing options...
Lessaj 63 Posted February 24 Share Posted February 24 They seem to be using a godaddy certificate, there shouldn't be anything wrong with it, unless it's a new CA that this Windows 7 machine doesn't have. You should really upgrade. 1 Link to comment Share on other sites More sharing options...
dialdown 0 Posted February 24 Author Share Posted February 24 2 hours ago, Luke said: So if you look at this: https://github.com/mpv-player/mpv/issues/4605#issuecomment-315417601 Looks like an issue with the remote host's certificate chain. I suppose we could always add an option to use --tls-verify=no Where did these trailers come from? That mpv-player issue seems to blame the remote site, and I might buy that if this didn't fail on all of them. It's not just this one trailer it is any and all trailers from the trailers plugin that won't play, and cinema intros all fail as well. These trailers came from the trailer plugin "New and Upcoming in Theaters" 1.3.8.0 Why does taking the URL from the log file and feeding to an official 6.1 (not emby modified 5.1-emby) ffmpeg binary on the same machine NOT result in an error? If it were something on my system or on the remote web server, then the official ffmpeg binary should fail too, but it doesn't. Do your patches not apply cleanly to the 6.x line(s)? Bottom line: official binary of ffmpeg 6.1 does not produce error emby modified ffmpeg does. 1 hour ago, Lessaj said: They seem to be using a godaddy certificate, there shouldn't be anything wrong with it, unless it's a new CA that this Windows 7 machine doesn't have. You should really upgrade. Do I sense a change to the official emby system minimum requirements? Link to comment Share on other sites More sharing options...
jaycedk 384 Posted February 24 Share Posted February 24 Windows 7, wen't eol 14-02-2020. Windows 7 support ended on January 14, 2020 - Microsoft Support So you should upgrade you OS. Link to comment Share on other sites More sharing options...
dialdown 0 Posted February 24 Author Share Posted February 24 (edited) 8 hours ago, jaycedk said: Windows 7, wen't eol 14-02-2020. Windows 7 support ended on January 14, 2020 - Microsoft Support So you should upgrade you OS. https://emby.media/support/articles/System-Requirements.html (accessed 2/24/20204 10:44 EST) Whether or not Microsoft supports Windows 7 for anything, Emby says they support it for running Emby and transcoding. stock ffmpeg 6.1 works and can access the remote content without the error, but emby-5.1 ffmpeg can't. If it were the OS stock ffmpeg 6.1 wouldn't work either. Edited February 24 by dialdown Link to comment Share on other sites More sharing options...
jaycedk 384 Posted February 24 Share Posted February 24 That might be. But your OS will not revive security updates or the like. DO Not blame any one but your self, if shit hits the fane. Link to comment Share on other sites More sharing options...
Lessaj 63 Posted February 24 Share Posted February 24 (edited) I won't claim to know what will happen regarding minimum OS requirements for Emby but indeed the fact of the matter is the OS is end of life and at some point you're going to have to upgrade it. I'm not 100% sure if it's the fault of the OS, but with a lack of updates it's a real possibility. CA certificates might have a long life span but they do eventually expire, and that can break things. In any case, I was only going off what's in the log provided. I don't use WIndows but I tried to replicate the command to some degree on my Linux system and I'm not 100% successful in creating the TS files but I do get further than you, it does seem to get the details from the file. I enabled some debugging and I can see the connection being made. Using the addresses that come up I actually can't get an SSL certificate from them, this likely means their web server is only figured to provide SSL when there is a match on the domain name and not just the IP, but it's likely printing IPs for the purpose of debug and is likely actually using the domain name, it does get a successful response and starts to try to process the stream. Using the domain name with openssl I can see the certificate and issuers in the chain. Opening an input file: https://cl.buscafs.com/www.metatube.com/public/uploads/videos/441172_mp4.mp4. [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] Opening 'https://cl.buscafs.com/www.metatube.com/public/uploads/videos/441172_mp4.mp4' for reading [https @ 0x18925c0] Setting default whitelist 'http,https,tls,rtp,tcp,udp,crypto,httpproxy' [tcp @ 0x1896980] Original list of addresses: [tcp @ 0x1896980] Address 8.240.147.124 port 443 [tcp @ 0x1896980] Address 8.252.7.252 port 443 [tcp @ 0x1896980] Address 8.240.248.124 port 443 [tcp @ 0x1896980] Interleaved list of addresses: [tcp @ 0x1896980] Address 8.240.147.124 port 443 [tcp @ 0x1896980] Address 8.252.7.252 port 443 [tcp @ 0x1896980] Address 8.240.248.124 port 443 [tcp @ 0x1896980] Starting connection attempt to 8.240.147.124 port 443 [tcp @ 0x1896980] Successfully connected to 8.240.147.124 port 443 [https @ 0x18925c0] request: GET /www.metatube.com/public/uploads/videos/441172_mp4.mp4 HTTP/1.1 User-Agent: Lavf/59.27.100 Accept: */* Range: bytes=0- Connection: close Host: cl.buscafs.com Icy-MetaData: 1 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] ISO: File Type Major Brand: isom [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] Unknown dref type 0x206c7275 size 12 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] Processing st: 0, edit list 0 - media time: 800, duration: 1776801 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] Offset DTS by 800 to make first pts zero. [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] Setting codecpar->delay to 2 for stream st: 0 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] Unknown dref type 0x206c7275 size 12 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] Processing st: 1, edit list 0 - media time: 1024, duration: 6540295 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] drop a frame at curr_cts: 0 @ 0 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] Before avformat_find_stream_info() pos: 151069 bytes read:163404 seeks:0 nb_streams:2 [h264 @ 0x18ae480] nal_unit_type: 7(SPS), nal_ref_idc: 3 [h264 @ 0x18ae480] nal_unit_type: 8(PPS), nal_ref_idc: 3 [h264 @ 0x18ae480] nal_unit_type: 7(SPS), nal_ref_idc: 3 [h264 @ 0x18ae480] nal_unit_type: 8(PPS), nal_ref_idc: 3 [h264 @ 0x18ae480] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0x18ae480] nal_unit_type: 5(IDR), nal_ref_idc: 3 [h264 @ 0x18ae480] Format yuv420p chosen by get_format(). [h264 @ 0x18ae480] Reinit context to 640x368, pix_fmt: yuv420p [h264 @ 0x18ae480] no picture [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] demuxer injecting skip 1024 / discard 0 [aac @ 0x18b32c0] skip 1024 / discard 0 samples due to side data [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] All info found [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1891c40] After avformat_find_stream_info() pos: 151927 bytes read:163404 seeks:0 frames:3 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'https://cl.buscafs.com/www.metatube.com/public/uploads/videos/441172_mp4.mp4': Certificate chain 0 s:CN=cl.buscafs.com i:C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Dec 11 11:03:37 2023 GMT; NotAfter: Jan 11 11:03:37 2025 GMT 1 s:C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2 i:C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: May 3 07:00:00 2011 GMT; NotAfter: May 3 07:00:00 2031 GMT 2 s:C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2 i:C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Jan 1 07:00:00 2014 GMT; NotAfter: May 30 07:00:00 2031 GMT Again, I'm not using Windows so I don't know exactly what ships with that version, but in a Linux version there is a small script which is used to set up environment variables needed for the ffmpeg that ships with Emby, including a line for SSL certificates which may or may not be used by ffmpeg. I'm not familiar with what ffmpeg may otherwise use as a CA certificate file/store. This "stub" might not be necessary on Windows, you might be able to run the ffmpeg command as is with some additional debugging (-loglevel debug) to get some more information about why it might be failing. APP_DIR=/opt/emby-server export SSL_CERT_FILE=$APP_DIR/etc/ssl/certs/ca-certificates.crt -rw-r--r--. 1 root root 222K Feb 7 16:06 /opt/emby-server/etc/ssl/certs/ca-certificates.crt Are you able to find a similar certificates file within the server directory on your side? I remember seeing some threads recently with some pfx files, which may also contain expired certificates. What output do you get if you try to run the ffmpeg command in the log but with -loglevel debug instead of -loglevel +timings? Note that you may need to adjust the paths slightly, the directories might not exist since they're temporary. Not looking for a successful conversion into TS files per se, just looking to see what information is available regarding opening the file from the URL. EDIT: You can also use the Diagnostic Options via Diagnostics Plugin to set the log level to Debug Information to try to get that information as well. Edited February 24 by Lessaj Diagnostic Options via Diagnostics Plugin 1 Link to comment Share on other sites More sharing options...
Happy2Play 8296 Posted February 24 Share Posted February 24 (edited) 4 hours ago, dialdown said: https://emby.media/support/articles/System-Requirements.html (accessed 2/24/20204 10:44 EST) Whether or not Microsoft supports Windows 7 for anything, Emby says they support it for running Emby and transcoding. stock ffmpeg 6.1 works and can access the remote content without the error, but emby-5.1 ffmpeg can't. If it were the OS stock ffmpeg 6.1 wouldn't work either. This will need to change eventually as ssl/tls within the OS becomes obsolete. Have not tested resently but would suggest this as cipher suite issue in Windows 7. You could start here. Logging doesn't really show it but this https://cl.buscafs.com lockdown would be the issue. Edited February 24 by Happy2Play Link to comment Share on other sites More sharing options...
Solution Happy2Play 8296 Posted February 24 Solution Share Posted February 24 (edited) Devs, with a patched Windows 7 it appears to work fine. So in the end all old platform users will need to ensure their systems support TLS 1.2 and they have the cipher suites any given site is looking for as site lockdowns will eventually exclude these platforms. ffmpeg-transcode-a9bd8189-e1da-4365-ae12-33c26f02f67d_1.txt Edited February 24 by Happy2Play 2 1 Link to comment Share on other sites More sharing options...
Luke 37099 Posted February 27 Share Posted February 27 @dialdownhas this helped? Link to comment Share on other sites More sharing options...
dialdown 0 Posted March 11 Author Share Posted March 11 On 2/27/2024 at 12:54 AM, Luke said: @dialdownhas this helped? No. My Windows 7 is fully patched. So saying it works on a fully patched windows 7 is not helpful. No one is still answering the question that a stock ffmpeg 6.1 CAN repeat can access that URL and produce output ON the same system. The EMBY supplied ffmpeg cannot. If it were a system patch issue or system configuration issue then ffmpeg 6.1 would NOT work either simple as. Link to comment Share on other sites More sharing options...
dialdown 0 Posted March 11 Author Share Posted March 11 On 2/24/2024 at 3:49 PM, Happy2Play said: Devs, with a patched Windows 7 it appears to work fine. So in the end all old platform users will need to ensure their systems support TLS 1.2 and they have the cipher suites any given site is looking for as site lockdowns will eventually exclude these platforms. ffmpeg-transcode-a9bd8189-e1da-4365-ae12-33c26f02f67d_1.txt 35.42 kB · 1 download Before you go marking MY issue as resolved, based on a "patched" windows 7, you should supply a list of every applied KB# patches to your system so it can be duplicated. My Windows 7 is fully as up-to-date with MS patches as it can be. So I reject your marking it a solution unless you supply that information and I can then verify it on my system. Saying "Works for me" is not a solution. Link to comment Share on other sites More sharing options...
dialdown 0 Posted March 11 Author Share Posted March 11 If you provide a way for me to substitute stock ffmpeg for Emby's ffmpeg that would solve my issue. How can it be my system patch level or configuration when stock ffmpeg 6.1 works and emby patched ffmpeg does not work? Link to comment Share on other sites More sharing options...
Happy2Play 8296 Posted March 11 Share Posted March 11 2 minutes ago, dialdown said: Before you go marking MY issue as resolved, based on a "patched" windows 7, you should supply a list of every applied KB# patches to your system so it can be duplicated. My Windows 7 is fully as up-to-date with MS patches as it can be. So I reject your marking it a solution unless you supply that information and I can then verify it on my system. Saying "Works for me" is not a solution. I didn't but per the log Emby supplied ffmpeg worked fine. As there are several Windows 7 topics and if you do not configure it properly to support TLS 1.2 and meet the provider sites ciphers there is nothing Emby can do. But since Windows 7 only has WEAK ciphers web security will eliminate it completely soon. Link to comment Share on other sites More sharing options...
dialdown 0 Posted March 11 Author Share Posted March 11 2 minutes ago, Happy2Play said: I didn't but per the log Emby supplied ffmpeg worked fine. As there are several Windows 7 topics and if you do not configure it properly to support TLS 1.2 and meet the provider sites ciphers there is nothing Emby can do. But since Windows 7 only has WEAK ciphers web security will eliminate it completely soon. Why does stock ffmpeg 6.1 work and emby's doesn't? Link to comment Share on other sites More sharing options...
Happy2Play 8296 Posted March 11 Share Posted March 11 (edited) 6 minutes ago, dialdown said: Why does stock ffmpeg 6.1 work and emby's doesn't? No idea a I just tested Emby with a machine configured with ciphers suites that match the Trailer provider site as shown above.. But as soon as Providers do their next required security lockdown it will eliminate Windows 7 as it does not have sufficient cipher suites. We had to beg metadata provides to loosen this restriction already to continue support for Windows 7. I guess you can try the Dianostics plugin as a temporary fix if it truly works. But not sure on how the custom feature works. Those options are intended to help investigating problems and should only be set when requested by Emby staff. None of those are intended to fix a problem for regular Emby operation. Settings made here will not be saved. They won't survive a server restart and might be automatically reset after some time. Edited March 11 by Happy2Play Link to comment Share on other sites More sharing options...
Happy2Play 8296 Posted March 11 Share Posted March 11 Note all I did was use IISCryto per the other linked topic. Link to comment Share on other sites More sharing options...
Happy2Play 8296 Posted March 12 Share Posted March 12 As mentioned in another topic the site security lockdown exceeds Windows 7 Ciphers now. Link to comment Share on other sites More sharing options...
rbjtech 4284 Posted March 12 Share Posted March 12 (edited) Really not sure why emby are supporting Windows 7 - seems a waste of support and testing resources imho. Give users notice, that from emby version x, it will no longer be supported - and lets all move on. The big .net change for 4.9 seems like a good opportunity ... Edited March 12 by rbjtech 2 Link to comment Share on other sites More sharing options...
Happy2Play 8296 Posted March 12 Share Posted March 12 3 minutes ago, rbjtech said: Really not sure why emby are supporting Windows 7 - seems a waste of support and testing resources imho. Give users notice, that from emby version x, it will no longer be supported - and lets all move on. The big .net change for 4.9 seems like a good opportunity ... In this situation it is not Emby that is the issue. But yes I think the time has come as I will expect other provider sites to be tightening ciphers. So Windows 7 will work if you have all your own metadata and don't expect any online interaction. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now