Sp3kt3r 13 Posted October 10, 2014 Share Posted October 10, 2014 (edited) Hi, I noticed that when I cast my recorded video (.WTV with WMC) to my Chromecast, they are transcoded at 480P I also have the same issue when I'm trying to play those video directly from the WebClient. I don't see other choices than 480P for the Quality Profile. I will post the log file soon... Edited October 15, 2014 by Sp3kt3r Link to comment Share on other sites More sharing options...
blade005 172 Posted October 11, 2014 Share Posted October 11, 2014 MBS Version 3.0.5395.0 File Container with issue: WTV Is anyone else experiencing issues with reported resolution of WMC Recorded TV files (WTV) in the Web Client with recent release? All Recorded TV that is 720p and 1080p resolution is being reported as 480p material in the Metadata Manager. After investigating further, I am now seeing that MEDIA INFO in Metadata Manager in WebUI is showing all of my 1080p (1920x1080) Recorded TV material as having a resolution of 704X480 (480p). I have opened the files with VLC and MPC and they are reporting and displaying the material as 1920X1080. I don't know what could have changed, because I know I have seen all of these items being reported with the proper resolution in the past. This seems to be an issue with only WTV files. All MKV and MP4 content that is 1080p or 720p is being reported correctly. Link to comment Share on other sites More sharing options...
blade005 172 Posted October 13, 2014 Share Posted October 13, 2014 MBS Version 3.0.5395.0 File Container with issue: WTV Is anyone else experiencing issues with reported resolution of WMC Recorded TV files (WTV) in the Web Client with recent release? All Recorded TV that is 720p and 1080p resolution is being reported as 480p material in the Metadata Manager. After investigating further, I am now seeing that MEDIA INFO in Metadata Manager in WebUI is showing all of my 1080p (1920x1080) Recorded TV material as having a resolution of 704X480 (480p). I have opened the files with VLC and MPC and they are reporting and displaying the material as 1920X1080. I don't know what could have changed, because I know I have seen all of these items being reported with the proper resolution in the past. This seems to be an issue with only WTV files. All MKV and MP4 content that is 1080p or 720p is being reported correctly. Luke, Could this be an issue with how WTV files are probed for Media Info during a library scan? Having all of these files reported incorrectly is an issue when they are transcoded to the Web Client or Android app. The aspect ratio is off and there are black bars on the left and right of the video, which shouldn't be the case. If they are direct played thru MBC or MBT there is no issue. As a test, I played a WTV file in the Android app with Internal Player and it was transcoded and the display issue is present. I went to the settings of the Android app and turned on the External Player, played the same WTV file as a direct play stream and no display issue. I am fairly certain that the issue is with how MBS is seeing and reporting the resolution of these files. Any thoughts would be appreciated. Would be happy to provide additional information or logs, if necessary. Just let me know what you may need to investigate further. Many thanks. Link to comment Share on other sites More sharing options...
Luke 37049 Posted October 13, 2014 Share Posted October 13, 2014 Try running them through ffprobe Link to comment Share on other sites More sharing options...
blade005 172 Posted October 14, 2014 Share Posted October 14, 2014 Try running them through ffprobe Have no idea how to use ffprobe. I can open any of these WTV files in external player or handbrake or vidcoder and they are all being read as 1920 x 1080 resolution. MB Server is showing the resolution as 704 x 480. Is there a guide for FFProbe for dummies that I can review? Link to comment Share on other sites More sharing options...
Sp3kt3r 13 Posted October 15, 2014 Author Share Posted October 15, 2014 (edited) After looking at the log and after multiple test. I can confirmed this: Playing Live either from Android or Web Client, the video is transcoded at the correct resolution (same as the broadcast channel) Playing the any recorded channel, the video is transcoded at 480P Metadata: encoder : Lavf56.7.104 Stream #0:0, 0, 1/90000: Video: h264 (libx264), yuv420p, 704x480, 1001/60000, q=-1--1, max. 5552 kb/s, 59.94 fps, 90k tbn, 59.94 tbc Log.txt Edited October 15, 2014 by Sp3kt3r Link to comment Share on other sites More sharing options...
Luke 37049 Posted October 15, 2014 Share Posted October 15, 2014 Right but if you look here Stream #0:2[0x46], 22, 1/10000000: Video: mpeg2video, yuv420p(tv), 704x480, 1001/120000, 17200 kb/s, 59.94 fps, 59.94 tbr, 10000k tbn, 119.88 tbc ffmpeg thinks the input is 704*440. There is nothing we're going to be able to do about that. You will probably want to file a report on their issue tracker. Link to comment Share on other sites More sharing options...
Sp3kt3r 13 Posted October 15, 2014 Author Share Posted October 15, 2014 Thx will do ! Link to comment Share on other sites More sharing options...
blade005 172 Posted October 15, 2014 Share Posted October 15, 2014 I am having this same symptom. Can we roll back until the ffmpeg devs address the issues or will that not help? I haven't had to look at squished HD in a long time. It hurts my eyes aghhhh. I agree!! Unwatchable in Web Client and Android app, or anything that requires a transcode of the source. At least I now know that I am not alone with this issue. It would be nice if there was an option to fall back to a previous version of ffmpeg and ffprobe. (Luke. Is this possible?) How 'lucky' for me that I recently moved about 500 WTV files that were all reported with the proper resolution and then a refresh scan is kicked off and they are all now incorrectly reported. Yea!!! LOL. Link to comment Share on other sites More sharing options...
bill the lizard 3 Posted October 16, 2014 Share Posted October 16, 2014 (edited) I am having this same symptom. Can we roll back until the ffmpeg devs address the issues or will that not help? I haven't had to look at squished HD in a long time. It hurts my eyes aghhhh. Edited October 15, 2014 by bill the lizard Link to comment Share on other sites More sharing options...
bill the lizard 3 Posted November 11, 2014 Share Posted November 11, 2014 This appears to have been fixed as of the 4th of November according to http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=2196 . Is there a way to incorporate the fix into my server? I am not sure how ffmpeg is implemented here. I have been without remote viewing on WTV for almost a month. They are stacking up. Link to comment Share on other sites More sharing options...
Redshirt 1487 Posted November 11, 2014 Share Posted November 11, 2014 The server is regularly updated to include newer ffmpeg builds. if you hang tight, the update will come to the server in the near future. Otherwise, I believe you can just overwrite the exe's that are in the ffmpeg folder of your server install. Link to comment Share on other sites More sharing options...
blade005 172 Posted November 11, 2014 Share Posted November 11, 2014 (edited) The server is regularly updated to include newer ffmpeg builds. if you hang tight, the update will come to the server in the near future. Otherwise, I believe you can just overwrite the exe's that are in the ffmpeg folder of your server install. I can confirm this works. I actually went back thru ffmpeg build archives and found that the ffmpeg and ffprobe exe's dated 9/4/2014 were the last ones to accurately read the resolution of WTV files. I replaced the exe's in the MB Server build, re-scanned the WTV files and all has been working well since. I did log a report on the ffmpeg forum awhile back with a test WTV file. Glad to hear that they may have corrected this. I will test with latest build and see how it goes. Redshirt, Does MBS use the 32-bit or 64-bit versions of ffmpeg? UPDATE: Downloaded the latest ffmpeg build dated 11/11/2014 from FFMPEG.org (ffmpeg-20141111-git-48efe9e-win32-static). Tested against a 1080p WTV file and resolution was reported accurately. Copied the ffmpeg and ffprobe exe's from this build and replaced the ones in the Mediabrowser Server FFMPEG folder. Played/Transcoded a 1080p WTV file thru the WebUI and Android client and videos were displayed in the correct aspect ratio. Edited November 11, 2014 by blade005 Link to comment Share on other sites More sharing options...
bill the lizard 3 Posted November 13, 2014 Share Posted November 13, 2014 (edited) How does one re-scan the recorded tv files? I am getting the correct aspect ratio now with the app and web interface but the maximum resolution is still 480p on the web interface. The android app doesn't provide the resolution data only bitrate so I am not sure. Thanks. I ran ffprobe on a particular file and it is showing the correct resolution. Not sure why web interface only offers 480p options for streaming at all bitrates. Edited November 12, 2014 by bill the lizard Link to comment Share on other sites More sharing options...
blade005 172 Posted November 13, 2014 Share Posted November 13, 2014 How does one re-scan the recorded tv files? I am getting the correct aspect ratio now with the app and web interface but the maximum resolution is still 480p on the web interface. The android app doesn't provide the resolution data only bitrate so I am not sure. Thanks. I ran ffprobe on a particular file and it is showing the correct resolution. Not sure why web interface only offers 480p options for streaming at all bitrates. Bill, I don't know of an elegant way to force a re-scan of all WTV files that are currently incorrectly identified in Media Browser. If they remain in the same location with the same file name, I could not get Media Browser to force a re-scan of the affected files. I actually renamed the folder containing the affected WTV files, scanned the library, then renamed it back to its original name and then scanned again. This allowed the files to be identified correctly. Like I said, not very elegant, but it worked. NOTE: Depending on the number of WTV files and if you have MBS create chapter images, this can be a long process that does eat up some CPU processing. 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