Channels Plugin

[infidel]

Code: Select all

admin@Athena:/opt/ums-3.0.0$ ffmpeg -protocols

Given that it's a system-installed ffmpeg, try deleting the symlinks and adding this to UMS.conf:

Code: Select all

ffmpeg_path = ffmpeg

[pen]

Oops, I edited the previous post while you where answering infidel. See last comment.

Anyway, I removed the symlink and added the path as suggested. No difference. Changed the path to the full one. No difference. Then I changed the path to nonsense:
ffmpeg_path = /usr/nonsens
and there is still no difference, i.e. I still get these lines in the log:
DEBUG 2013-11-16 19:07:49.154 [main] FFmpeg supported protocols: [mms, https]
INFO 2013-11-16 19:07:49.154 [main] Registering transcoding engine: FFmpeg Web Video
very strange!

By the way, I tried the same redirect when I installed UMS 2.6.5 but it didn't work, the "/" were messed up as usual when there is a missmatch between Windows and Linux. That's why I ended up in using symlinks instead.

Pen

[infidel]

• The [mms, https] protocols are added automatically no matter what (see source) in a not-too-smart way it turns out, we'll need to fix it.
• Is your 2.6.5 install local to your user? That may be the critical difference. In my case UMS is a local install.

when I installed UMS 2.6.5 but it didn't work, the "/" were messed up.

Was fixed recently (n.b. SharkHunter ).

[pen]

• The [mms, https] protocols are added automatically no matter what (see source) in a not-too-smart way it turns out, we'll need to fix it.
• Is your 2.6.5 install local to your user? That may be the critical difference. In my case UMS is a local install.

Well, I'm not 100% sure what you mean by local install. But there is indeed a difference. Both are installed with UMS root directory in the /opt. But:

UMS 2.6.5:
Patched the UMS.sh with
# Setup UMS_PROFILE (added by Pen)
# This forces UMS to use the config files in the PMS_HOME directory instead of the one in ~/.config/UMS
UMS_PROFILE=$PMS_HOME
export UMS_PROFILE
The reason to this is that I want UMS to use the UMS root directory for the config irregardless of if I start it manually from command line or automatically from the /etc/init. This makes it much easier to debug since UMS starts in the same environment. Note that when I compare 2.6.5 and 3.0.0 I always start them from command line and not automatically.

UMS 3.0.0:
No patches, so all config, debugs and so on are in the ~/.config/UMS directory.

Hope this answer the question.

In the end, I will adjust 3.0.0 to start as a service as well. It's a headless server.

Pen

[infidel]

Well, I'm not 100% sure what you mean by local install.

Well I could have phrased it better: I meant a standalone, not system, installation. I was looking for some sort of difference between your 2 installs privilege-wise. My only other suggestion is to untar another ums-3.0.0 at some random spot and see how it behaves.

EDIT: Same problem/different situation: I followed my own advice and untarred a test ums-3.0.0 and found, as others have reported, that the current UMS linux ffmpeg binary segfaults, producing a debug.log similar to yours:

DEBUG 2013-11-16 16:23:04.764 [main] FFmpeg supported protocols: [mms, https]

but it works ok if I point to my system ffmpeg.

[pen]

The strange thing is that I get that line
DEBUG 2013-11-17 10:30:57.919 [main] FFmpeg supported protocols: [mms, https]
in all these scenarios:
- UMS 2.6.5 with redirect to the system ffmpeg and which is working well
- UMS 2.6.5 where I have completely removed all ffmpegs from the system
- UMS 3.0.0 with redirect to the system ffmpeg and which is the failing one
- UMS 3.0.0 where I have completely removed all ffmpegs from the system
.. but that's maybe what you have already pointed out.
Anyway, that line doesn't give so much information on the health as it looks.
Also everything else looks the same in the registration phase.

It seems that the only differentiator in the log is when I try to start web-media:
TRACE 2013-11-17 10:58:11.762 [New I/O worker #2] Player "FFmpeg Web Video" is incompatible
So, somehow it already knows and don't even try ffmpeg here.

Can you give me a hint what is actually done in the registration phase? Is UMS running the ffmpeg command during that phase to discover the capabilities? If not, how does it else decide the capabilities? Basically, when it comes to the "FFmpeg Web Video is incompatible" printout, has it even run ffmpeg at that stage?

I think answers on these questions can help me to take the next debugging step.

Also, if you can point me to the code where the two steps takes place (registration, compatibility check)? I got the code pointer above - but I'm not clear on if it includes these two steps.

Last, what version/build of ffmpeg are u using infidel? Can you make a ffmpeg -protocols and share the printout?

Thanks
Pen

[infidel]

pen, the answer (or part if it, anyway) was right in front of me but I didn't see . You're using a different flavor of ffmpeg (maybe sourced from libav.org not ffmpeg.org, see here about the ffmpeg civil war) and your output of 'ffmpeg -protocols' is incompatible with the UMS parsing code, which expects to see this

Supported file protocols:
Input:
applehttp
cache
concat
crypto

and not this

I.. = Input supported
.O. = Output supported
..S = Seek supported
FLAGS NAME
-----
I.. applehttp
I.S cache
I.S concat
I.. crypto

So for now the workaround is to try a compatible ffmpeg version:

• static builds or distro package.
• or roll your own custom build of ffmpeg (which is what I do). If you want to go this route add the following options to the given ffmpeg configure command

  Code: Select all

  --enable-librtmp --enable-libfreetype --enable-fontconfig --enable-libv4l2 --enable-openssl

  you may have to install some packages first:

  Code: Select all

  sudo apt-get install rtmpdump libfreetype6-dev libfontconfig1-dev

but it still doesn't explain why 2.6.5 works for you and not 3.0.0, which I'll look into.


EDIT: it's an old output format, unrelated to ffmpeg/libav differences.

EDIT2: put this update.jar next to ums.jar in your 3.0.0 install folder and see if it works for your old-style ffmpeg binary:

update-protocols.zip

(14.4 KiB) Downloaded 954 times

[pen]

Oh, I didn't know there were two dialects of ffmpeg - and it was interesting to read about the "war".

But, the one that you pointed me out to download is Jon Severins build, and that is exactly the one I have installed. So, then I think I have the dialect you propose me to have - correct? However, my version of Jon Severins build is 6:0.10.7 (see ffmpeg printout) - it's around 6 month now. I can see that the one on the homepage now is 7:0.10.9.

Anyway, I tried your patch and - vola - it works:

Code: Select all

DEBUG 2013-11-18 20:27:16.034 [main] FFmpeg supported protocols: [applehttp, cache, concat, crypto, file, gopher, http, httpproxy, https, mmsh, mmst, pipe, rtmp, rtmpt, rtmpe, rtmpte, rtmps, rtp, tcp, tls, udp, mms, https]

So, thank's alot infidel

B.t.w. will your patch be merged into a release or am I better upgrading my ffmpeg to stay compatible in the future? I'm a bit reluctant though since I have a second media server on the same ffmpeg.

Pen

[infidel]

vola - it works

will your patch be merged into a release or am I better upgrading my ffmpeg to stay compatible in the future?

yes and yes (don't worry, you're not likely to break anything by updating).

[redonyx]

Updated to 3.1.0, installed Channels 2.22. When I go on Icefilms and select a show, I can see the sources but I can't exactly select a source to watch. Unless I go under releases, navigate to that same show, I can then select a source but then get "There are no titles". Also, sometimes no episode or source will show up.

EDIT: I'm also having a problem where I'm trying to play a .mp4 file, I'd either get a "Data is corrupted" or "This content can't be played". When I check my log files I see:

11-19 23:22:13 Media renderer was not recognized. Possible identifying HTTP headers: User-Agent: UPnP/1.0, X-AV-Client-Info: av=5.0; cn="Sony"; mn="LT30a"; mv="2.0";

right after the error happens. I have no clear idea what that means but I do have an LT30a in my household. Don't know how that would interfere with this...