Chapter name over timeline weird text wrapping

[smowtenshi]

mpv version: 0.35.0 uosc version: 4.4.0

There's a possibility I overlooked something, but comparing it as described in pull #93, the whole behavior of text wrapping has changed.

Compared to uosc version 4.0.0:

[christoph-heinrich]

Can't reproduce :neutral_face: In #354 the text width estimation sometimes thinks that text has 0 width while here it seems to think that text is much wider then it actually is. No idea why that sometimes fails for some people.

Everything else looks fine? Background of the title is the right width? Menu is also sized correctly? Do you have text_width_estimation set to yes or no?

We recently had an issue that turned out to be a luajit bug, and now I'm awfully curious if there is a change in those text width related issues when people try using lua instead. Do you know which one you are using?

Edit: I've posted a patch in https://github.com/tomasklaen/uosc/issues/354#issuecomment-1320960600 that might influence what's going on here. Can you please try that?

[smowtenshi]

Everything else looks fine? Background of the title is the right width? Menu is also sized correctly? Do you have text_width_estimation set to yes or no?

I've tried both options with no success. Though yes, everything else seem to be correct.

We recently had an issue that turned out to be a luajit bug, and now I'm awfully curious if there is a change in those text width related issues when people try using lua instead. Do you know which one you are using?

Looks like I have lua, lua51, lua52 and luajit installed and I see [ 0.007][v][cplayer] List of enabled features: [...] lua luajit [...] in logs, but I'm not really sure which one is mpv using.

Edit: I've posted a patch in #354 (comment) that might influence what's going on here. Can you please try that?

Well, it seems no configuration

text_osd.compute_bounds, text_osd.hidden = true, true
local bounds_opts = {wrap = 2, bold = false, italic = false, rotate = 0, size = 0, opacity = 0}
-- nor this
text_osd.compute_bounds, text_osd.hidden = true, false
local bounds_opts = {wrap = 2, bold = false, italic = false, rotate = 0, size = 0}
-- this neither
text_osd.compute_bounds, text_osd.hidden = true, false
local bounds_opts = {wrap = 2, bold = false, italic = false, rotate = 0, size = 0, opacity = 0}

of that patch and text_width_estimation (yes/no) option is able to change anything.

[christoph-heinrich]

I've only now noticed that the clamping of the text position seems to use the width that the text is supposed to have, which indicates that the wrapping itself actually works as it's supposed to, but I have no idea why it's then shown with only one word per line. @tomasklaen any ideas?

[ 0.007][v][cplayer] List of enabled features: [...] lua luajit [...]

Looks like you're using luajit. I think the easiest way of trying it with lua would be to build mpv with mpv-build, which should default to lua if both are available. After compilation the binary can be found in mpv/build/mpv. Due to my realization above I don't think it'll make a difference, but if you're still willing to try it, then at least we know for sure.

Well, it seems no configuration of that patch and text_width_estimation (yes/no) option is able to change anything.

Thanks for testing.

[tomasklaen]

This might have nothing to do with hints. It's just when title/hint cut coordinates are calculated, the title will always be hidden in favor of hint if its width is 0. And the items with no hints just render at menu min width config.

I think we should create an isolated script that does some test measurements on load and a couple half a second increments afterwards, and report circumstances where the width is measured as 0.

I have no other ideas. The only clue seems to be that this seems to happen only on asian PCs, but I have no idea what might they have in common to cause this.

[christoph-heinrich]

The log from https://github.com/tomasklaen/uosc/issues/354#issuecomment-1297190975 shows it never happens for hint. I find it hard to believe that the timing just happens to work out like that for hundreds of items. Also there is a pattern where it does work for some titles, then it doesn't work anymore for ~65 items, then it works again for a few titles, then again there are ~65 of them where it doesn't work, then it works again for a few, and then it stops working again for ~65 of them, then it works for a few, and once again it stops working for ~65 followed by a few that do work, after which it stops working again. Meanwhile hints always work right in between the titles.

[smowtenshi]

Looks like you're using luajit. I think the easiest way of trying it with lua would be to build mpv with mpv-build, which should default to lua if both are available. After compilation the binary can be found in mpv/build/mpv. Due to my realization above I don't think it'll make a difference, but if you're still willing to try it, then at least we know for sure.

I actually tried building it all, with default options and I ran into another issues with it. Though compilation ends with a success, scripts load just fine, nothing seem to work properly. So I tried running it another way, namely ./mpv/build/mpv --no-config --osc=no --osd-bar=no --log-file=mpv.log --script=uosc/scripts/uosc.lua "Hyouka - 04.mkv" (logs) with uosc git cloned, to make sure no config option is messing with it.

The error I'm getting with this command is 🤔

[uosc]
[uosc] stack traceback:
[uosc]  uosc/scripts/uosc.lua:13: in main chunk
[uosc]  [C]: in ?
[uosc]  [C]: in ?
[uosc] Lua error: uosc/scripts/uosc.lua:13: attempt to concatenate a nil value

Also, looks like reported Lua is now lua lua52.

[christoph-heinrich]

Lua error: uosc/scripts/uosc.lua:13: attempt to concatenate a nil value

It fails to load it's dependencies. When I try that command I get the same thing. I guess that just doesn't work with --script :shrug:.

nothing seem to work properly

Do you have a log of running mpv like you usually would but with the binary you compiled yourself?

[smowtenshi]

nothing seem to work properly

Do you have a log of running mpv like you usually would but with the binary you compiled yourself?

Sure https://gist.github.com/smowtenshi/0e43cf0ecaa9bd893b8e910c02fbce83

[christoph-heinrich]

I don't see anything wrong in that log, but it has tons of shader output which mine doesn't when I try to run it in as close to the same context as possible (--vo=gpu --gpu-api=opengl --gpu-context=x11egl and compiled with lua interpreter).

I assume "nothing seem to work properly" means it's not uosc specific? If things also don't work without uosc, then it seems like you ran into a problem with mpv itself and might want to open an issue about it over there.

[smowtenshi]

it has tons of shader output which mine doesn't when I try to run it in as close to the same context as possible (--vo=gpu --gpu-api=opengl --gpu-context=x11egl and compiled with lua interpreter).

Shader output comes from Anime4K shaders v.4.0.1 with config for profile named Anime:

# ~/.config/mpv/mpv.conf
[Anime]
profile-desc="Anime videos"
profile-cond=string.find((path or ''), '/smow/Anime/') ~= nil
## apply hardware decoding from default disabled
hwdec=nvdec
## set Anime4K A+A (HQ) shaders
glsl-shaders="~~/shaders/Anime4K_Clamp_Highlights.glsl:~~/shaders/Anime4K_Restore_CNN_VL.glsl:~~/shaders/Anime4K_Upscale_CNN_x2_VL.glsl:~~/shaders/Anime4K_Restore_CNN_M.glsl:~~/shaders/Anime4K_AutoDownscalePre_x2.glsl:~~/shaders/Anime4K_AutoDownscalePre_x4.glsl:~~/shaders/Anime4K_Upscale_CNN_x2_M.glsl"

I assume "nothing seem to work properly" means it's not uosc specific? If things also don't work without uosc, then it seems like you ran into a problem with mpv itself and might want to open an issue about it over there.

Actually, it looks like running compiled mpv binary with --no-config and without uosc, works just fine. I tried duplicating ~/.config/mpv/ directory and pulling uosc from master once again, and... it looks like it works? Both on system mpv and the one I compiled myself. The text looks different from v4.0.0, but I think I'm content with it.

Thank you for your time. :bow:

[tomasklaen]

Seems like not a uosc related issue after all, so I'm gonna close this. If someone figures out what is the cause of this and there's anything we can do to prevent it, like note in readme or something, let me know.