psi 1 Posted December 6, 2015 Author Posted December 6, 2015 OK, i looked at the web interface, (without changing the ruko app) and for a transcoding file i get this; Media Info Container mp4 Path /mytv/detectorists/series 2/Detectorists_Series_2_-_3._Episode_3_b06nxyd8_default.mp4 Size 310 MB and for a non-transcoding file, i mostly get all this; (same file encoding as above.) (some non-transcoding files are also showing absolutely nothing, not even above info.) Media Info Video CodecH264ProfileMainLevel31Resolution832x468Aspect ratio16:9AnamorphicNoInterlacedNoFramerate25Bitrate1371 kbpsBit depth8 bitPixel formatyuv420pRef frames2CABACNo Audio LanguageundCodecAACProfileLCLayoutstereoChannels2 chBitrate91 kbpsSample rate48000 khzDefaultYes Containermp4 Path/mytv/last kingdom/The_Last_Kingdom_-_6._Episode_6_b06qrbsr_default.mp4
speechles 2055 Posted December 6, 2015 Posted December 6, 2015 (edited) @@psi, going strictly off that transcoding section this file should not be transcoding. The roku direct play profile should just let this happen. Maybe it isnt doing that? (O_o);; What version of the server are you using? There is something fishy going on here. Maybe we need a bigger boat? I mean.. *cue jaws music* .. I really mean, the problem doesn't appear to be your files. It is weird. Does this happen with any other files? Maybe it is because they arent properly identified as in, they dont get full metadata because the filenames arent fitting the norm. So your description is missing too. But this should not cause the server to neglect filling in the codec names. We may have to wait for @@Luke to follow up on this when he has time and see if he can find this white whale they call moby. A bigger boat indeed is required there. Last joke, I promise. Haw.. Trying to keep this light and keep it friendly. Edited December 6, 2015 by speechles
psi 1 Posted December 6, 2015 Author Posted December 6, 2015 Version 3.0.5781.4 i'll just try shortening the names and see what happens. perhaps a sonic screwdriver?
psi 1 Posted December 6, 2015 Author Posted December 6, 2015 wow, must have been the dr Who reference, but i worked!!! i noticed the problem file was slightly longer at 53, than the other at only 47. so a file name limit of 50 chars perhaps?
psi 1 Posted December 6, 2015 Author Posted December 6, 2015 OK tried more files and they are all fixed, so no more crappy quality viewing. but it doesn't appear to be just the length of file name, some i made longer but they still work, so i guess the name change caused a re-check and things worked the second time. maybe its the initial scan, during setup, that goes wrong, then to trigger a re-check you have to rename, otherwise a rescan just assumes what it had already was right.
psi 1 Posted December 6, 2015 Author Posted December 6, 2015 should add; transcoding always stops when you get the long list of meta-data to appear, and files with only the short list always transcode.
ebr 16169 Posted December 7, 2015 Posted December 7, 2015 OK, i looked at the web interface, (without changing the ruko app) and for a transcoding file i get this; Media Info Container mp4 Path /mytv/detectorists/series 2/Detectorists_Series_2_-_3._Episode_3_b06nxyd8_default.mp4 Size 310 MB and for a non-transcoding file, i mostly get all this; (same file encoding as above.) (some non-transcoding files are also showing absolutely nothing, not even above info.) Media Info VideoCodecH264ProfileMain Level31 Resolution832x468 Aspect ratio16:9 AnamorphicNo InterlacedNo Framerate25 Bitrate1371 kbps Bit depth8 bit Pixel formatyuv420p Ref frames2 CABACNo AudioLanguageundCodecAAC ProfileLC Layoutstereo Channels2 ch Bitrate91 kbps Sample rate48000 khz DefaultYes Containermp4 Path/mytv/last kingdom/The_Last_Kingdom_-_6._Episode_6_b06qrbsr_default.mp4 This makes sense. The files that we had no media information for were transcoded because we had no way of knowing otherwise. Renaming the files caused them to be re-added and re-scanned which then got proper media info for them. Refreshing them probably would have accomplished the same thing.
psi 1 Posted December 7, 2015 Author Posted December 7, 2015 This makes sense. The files that we had no media information for were transcoded because we had no way of knowing otherwise. Renaming the files caused them to be re-added and re-scanned which then got proper media info for them. Refreshing them probably would have accomplished the same thing. OK, yes the conclusion i came to. but what do you mean by "refreshing"
bluemonkey07 590 Posted December 7, 2015 Posted December 7, 2015 (edited) Select to refresh the item in the web client, rescans the item and metadata/mediainfo Edited December 7, 2015 by Vidman
psi 1 Posted December 7, 2015 Author Posted December 7, 2015 OK, found it and that worked. so refresh re-scans, and that works, then why isn't the initial scan working? or the scan on startup, seems the fundamental issue. i have repeatedly tried hitting the 'scan' command in the web interface to no avail. also having to 'refresh' every file is certainly a bit clumsy. just had to 'refresh' a file i added yesterday! that was happily in the libarary but without all the meta-data again.
ebr 16169 Posted December 7, 2015 Posted December 7, 2015 A scan and a refresh are two different things. A scan searches your entire library for anything that has changed since it was last refreshed and refreshes only those items. A refresh actually refreshes the information. So, if those items hadn't changed in some way that we could discover and (for whatever reason) they were not able to be properly interrogated for media info when first ingested, then a scan would not affect them at all.
psi 1 Posted December 7, 2015 Author Posted December 7, 2015 so scanning is broken? not firing off refreshing? even when it does find new files. A scan searches your entire library for anything that has changed since it was last refreshed and refreshes only those items.
ebr 16169 Posted December 7, 2015 Posted December 7, 2015 No, I doubt it is broken. More than likely, there was just a problem getting that info when those were first ingested and nothing about them has changed since. If we re-proved for that on every scan, they would all take forever.
psi 1 Posted December 7, 2015 Author Posted December 7, 2015 just a problem getting that info when those were first ingested so not a problem? even given; just had to 'refresh' a file i added yesterday! that was happily in the libarary but without all the meta-data again. if there's no chance of this being viewed as a bug, what ever i say, then lets forget it, i've already spent a long and frustrating time here.
ebr 16169 Posted December 8, 2015 Posted December 8, 2015 Any number of things could be going on to cause that. What we'd need to see is the log from when that item was first ingested and know what the item is. Thx.
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