| Xenguy | rwp, Good tip, seems to work in both tmux and screen, so no need to remember different methods for each | 05:31 |
|---|---|---|
| Xenguy | 'q' FTW | 05:32 |
| rwp | \o/ | 06:08 |
| gnarface | i guess i didn't notice the scrollback thing because most my headless systems are on older kernels than that... | 07:49 |
| gnarface | what a shame | 07:49 |
| cousin_luigi | So, does anyone use hardware flow control on console ports? | 09:11 |
| _al1r4d | i have a question | 09:13 |
| _al1r4d | how to disable cups-browser? | 09:14 |
| gnarface | not clear on what it's for really, but on the one set of ARM devices i regularly use, the instructions from the community have been to explicitly disable hardware and software flow control | 09:14 |
| _al1r4d | already did update-rc.d but not ok for the results | 09:14 |
| gnarface | _al1r4d: not sure what cups-browser is, do you just mean CUPS the printer daemon? | 09:14 |
| _al1r4d | yeah, cupsd, gnarface | 09:15 |
| gnarface | _al1r4d: oh, it's not good enough to remove the symlinks. change them all from S to K | 09:15 |
| gnarface | depending on how you called update-rc.d it may have just removed them | 09:15 |
| _al1r4d | update-rc.d cups remove | 09:16 |
| gnarface | i think you want disable instead of remove, but check the man page (i usually just do them by hand) | 09:16 |
| gnarface | i also put K01cups symlinks even in the runlevels were there wasn't a corresponding S* one | 09:16 |
| gnarface | that took it offline | 09:16 |
| gnarface | you'll probably want to do the same thing for saned if you have it too | 09:16 |
| gnarface | there's a way to call update-rc.d with more specificity, it might help | 09:18 |
| gnarface | really, creating the symlinks by hand is easier to figure out though | 09:18 |
| gnarface | should look like this when you're done: https://paste.debian.net/1322647/ | 09:19 |
| gnarface | (note that they're relative-path symlinks instead of absolute-path is important, though i can't remember exactly why) | 09:19 |
| _al1r4d | okay | 09:19 |
| _al1r4d | thank you | 09:19 |
| gnarface | no problem | 09:19 |
| _al1r4d | sudo update-rc.d -f cups defaults k | 09:20 |
| _al1r4d | like this? | 09:20 |
| gnarface | uh, not sure | 09:20 |
| gnarface | just check the output of "ls -l /etc/rc*.d/*cups*" when you're done to verify | 09:21 |
| gnarface | i thought it was something more like: update-rc.d -f cups disable 123456 | 09:21 |
| _al1r4d | gnarface | 09:22 |
| _al1r4d | https://paste.debian.net/1322648/ | 09:22 |
| _al1r4d | not all services are K01 like yours | 09:22 |
| gnarface | yea, cups-browsed is different. you'll have to disable that one too i guess. i don't know what that even is, i print fine without it installed. | 09:22 |
| gnarface | ymmv (maybe differnet printers need it?) | 09:23 |
| gnarface | *different | 09:23 |
| gnarface | it should be disableable the same way as cups, this in fact should work in general for all the daemons | 09:23 |
| _al1r4d | ls -l /etc/rc*.d/*cups | 09:25 |
| _al1r4d | lrwxrwxrwx 1 root root 14 Jul 8 14:19 /etc/rc1.d/K01cups -> ../init.d/cups | 09:25 |
| _al1r4d | lrwxrwxrwx 1 root root 14 Jul 8 14:19 /etc/rc2.d/S04cups -> ../init.d/cups | 09:25 |
| _al1r4d | lrwxrwxrwx 1 root root 14 Jul 8 14:19 /etc/rc3.d/S04cups -> ../init.d/cups | 09:25 |
| _al1r4d | lrwxrwxrwx 1 root root 14 Jul 8 14:19 /etc/rc4.d/S04cups -> ../init.d/cups | 09:25 |
| _al1r4d | lrwxrwxrwx 1 root root 14 Jul 8 14:19 /etc/rc5.d/S04cups -> ../init.d/cups | 09:25 |
| _al1r4d | okay | 09:25 |
| _al1r4d | hmm | 09:25 |
| _al1r4d | not all k01 | 09:25 |
| gnarface | they're just symlinks, you can create them by hand with ln -s [target] [name] | 09:38 |
| gnarface | or rename them with mv | 09:38 |
| gnarface | they're neat but they're neither complex or magical | 09:39 |
| systemdlete | I suppose I shouldn't complain, and I don't want to jinx it, but the apt-cacher-ng has been working without problems for the better part of a week now. I say "better part of" because it has occasionally glitched here and there, although not anywhere close to the headache it was creating earlier on. | 09:42 |
| gnarface | i still think that eventually it's going to be traced to an anomaly that can only be fixed at the repo side | 09:42 |
| gnarface | it's gotta be something that just a few of them do... differently | 09:43 |
| systemdlete | gnarface, I hope whatever we find out, we find out sooner than later. Thank goodness there haven't been any great number of updates recently, although there was that one great big one this past week with the new kernel and dozens of other things. | 09:43 |
| gnarface | maybe not wrong exactly, but something apt-cacher-ng can't handle because of its inherent nature as a proxy | 09:43 |
| systemdlete | And--get this, gnarface--not a single glitch updating about a dozen VMs and hosts. | 09:44 |
| gnarface | huh, interesting | 09:44 |
| gnarface | that's probably statistically relevant | 09:44 |
| systemdlete | actually, no. I lied. about half a dozen. | 09:44 |
| systemdlete | so: Only do VERY LARGE UPGRADES. | 09:45 |
| systemdlete | (infrequently) | 09:45 |
| systemdlete | I had all of them chugging simultaneously, too. | 09:45 |
| gnarface | hmm | 09:45 |
| systemdlete | yeah. Makes ya think | 09:45 |
| systemdlete | On a slightly differnt topic: Any experience with NUT? (Network UPS Tools) | 09:47 |
| systemdlete | I have 2 different models of APC UPSs that have identical USB vendor and product IDs. (The standards people draft a standard, and then the mfrs... ah, nvm) | 09:48 |
| adhoc | the vendor probably uses the exact same USB module in their products ... | 09:49 |
| systemdlete | the drive, usbhid-ups, continually dies and restarts, making its usefulness somewhat shaky | 09:49 |
| adhoc | the vendor just sees the USB thingy as a replacement for the Derial port? | 09:49 |
| adhoc | serial port | 09:50 |
| systemdlete | sure, makes sense enough | 09:50 |
| adhoc | and not product in itself | 09:50 |
| systemdlete | but that means the API to the device should be the same... oh, wait. | 09:50 |
| systemdlete | maybe not. | 09:50 |
| adhoc | the module has "a" venfor and "a" product ID | 09:51 |
| systemdlete | but anyway, aside from the problems of differentiating them, which NUT does all right, | 09:51 |
| adhoc | and not that the thing it plugs into is different | 09:51 |
| adhoc | NUT probes the UPS direclty | 09:51 |
| adhoc | ? | 09:51 |
| LucentW | systemdlete: you might make your own serial cable, usually APC UPSes have both USB and serial | 09:51 |
| systemdlete | well, the driver keeps flaking on me | 09:51 |
| LucentW | so you can use NUT instead of HID shenanigans | 09:51 |
| adhoc | usd the serrial port directly | 09:51 |
| systemdlete | these are both USB only | 09:52 |
| adhoc | =/ | 09:52 |
| adhoc | it may have a serial port internally | 09:52 |
| adhoc | APC has dropped its standards a lot over the years | 09:53 |
| LucentW | it should have a fake Ethernet port which actually is serial | 09:53 |
| adhoc | an RJ45 connector? | 09:53 |
| LucentW | yes, it's a RJ45 but actually it's a custom serial, it's not the "standard" RJ45 to RS232, you need to wire your own | 09:54 |
| adhoc | joy | 09:54 |
| LucentW | but it's fairly easy, at previous job I made my own to reset the battery status when I replaced them so I didn't have to bother having a whole setup of their PowerChute to do the same thing | 09:55 |
| systemdlete | The XS1300 has a RJ45 to USB connector, and the cable comes with it. | 09:55 |
| systemdlete | The ES650 iirc, is just a standard USB A-B cable | 09:56 |
| systemdlete | sometimes mfrs will change these features and not so much as change the carton, let alone the UPC code and instructions. | 09:56 |
| systemdlete | so it is quite possible that these had serial ports in the olden days | 09:57 |
| LucentW | if you check the 'net, you should be able to find plenty of resources about folks using serial even on USB or network-aware UPSes | 09:57 |
| LucentW | I mean, serial pretty much needs only 3 pins to work if you don't need further signaling | 09:57 |
| LucentW | as in RX, TX and ground | 09:57 |
| systemdlete | so, let me understand: I can *possibly* connect that RJ45 to a (somewhat) normal CAT6 cable? | 09:58 |
| LucentW | so over a 8c RJ45 they can fit both USB and serial interfaces | 09:58 |
| LucentW | but on different pins, obviouslt | 09:58 |
| systemdlete | "can" fit... | 09:58 |
| systemdlete | Q: Does it cause the unit to catch fire, burn up, and explode if wired incorrectly? | 09:58 |
| systemdlete | (I'm serious. I'm a EE noob) | 09:59 |
| LucentW | nah, it got protections, if you wire them incorrectly the UPS turns off | 09:59 |
| LucentW | been there, done that | 09:59 |
| gnarface | systemdlete: heh, no, i dont' attach my UPSes to the network. i watched MR Robot. | 09:59 |
| systemdlete | What about the other unit, the ES650? | 10:00 |
| systemdlete | I don't recall anything other than a USB on that one | 10:00 |
| systemdlete | (this is for science, only) | 10:02 |
| systemdlete | You know what, the ES650 might have surge suppression filters for ethernet. | 10:09 |
| systemdlete | I wonder if those can be used for monitoring? | 10:09 |
| systemdlete | specs for the XS1300: Interface--USB and Serial | 10:44 |
| fonkey | hey all | 14:01 |
| gordonDrogon | Not specifically a Devuan issue, but maybe some kind soul here has a pointer: Video playback (MP4 off my GoPro) played in firefox work fine - nice and smooth, but in VLC it's somewhat frame rate limited - audio is fine it just appears a bit jerky. It works well in both on my laptop though. Desktop has been upgraded from B to C and now D. Laptop was a fresh install of D. | 14:39 |
| gordonDrogon | I suspect some configuration somewhere might at an issue - especially as I recall having some video issues when I did the upgrade but I really can't recall what it was back then. | 14:40 |
| djph | simplest test to rule out a systemic issue --> create a temporary / test user on the desktop, and verify VLC behaves now | 14:41 |
| gordonDrogon | ah, so environment thingy. | 14:43 |
| fsmithred | Different graphics hardware? Does one need firmware? | 14:48 |
| gordonDrogon | well ,same with a different user. | 14:49 |
| gordonDrogon | fsmithred, same PC - Firefox: OK, VLC: jittery. | 14:49 |
| amarsh04 | installing mpv and trying different --hwdec= options can help identify if a specific hardware decoder has problems | 14:50 |
| amarsh04 | it's a little quicker to try that than change vlc settings, then quit and restart vlc | 14:50 |
| gnarface | gordonDrogon: first idea that comes to mind is make sure you have both the vdpau and vaapi driver packages for your video hardware installed | 14:53 |
| gordonDrogon | I'm fairly sure it's all there else what might firefox be using.. | 14:55 |
| gnarface | that's the point | 14:55 |
| gnarface | firefox is using vaapi | 14:55 |
| gnarface | most stuff uses vdpau though | 14:55 |
| gnarface | most modern video cards support both | 14:55 |
| gnarface | initially, vaapi was the intel offering, and vdpau was the nvidia offering | 14:56 |
| gnarface | if the desktop where it's both working is amd or nvidia, but the laptop is older intel though, it might be an actual hardware limitation... | 14:56 |
| gnarface | or, sorry, switch those | 14:57 |
| gordonDrogon | it's a dell something with on-board graphics. | 14:57 |
| gnarface | those are usually intel | 14:58 |
| gordonDrogon | it is. | 14:58 |
| amarsh04 | lspci can identify it quickly | 14:58 |
| gnarface | can't hurt to try it | 14:58 |
| gordonDrogon | 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) | 14:58 |
| gnarface | just make sure you have both mesa-vdpau-drivers and mesa-va-drivers | 14:59 |
| gnarface | here, when in doubt just install everything i've got: https://paste.debian.net/1322667/ | 15:01 |
| gordonDrogon | ii mesa-va-drivers:amd64 22.3.6-1+deb12u1 amd64 Mesa VA-API video acceleration drivers | 15:01 |
| gordonDrogon | ii mesa-vdpau-drivers:amd64 22.3.6-1+deb12u1 amd64 Mesa VDPAU video acceleration drivers | 15:01 |
| gordonDrogon | I appear to have both,. | 15:01 |
| gnarface | hmmm | 15:01 |
| gnarface | might just be that the hardware can't do vdpau, and vlc insists on it, but maybe there's a way to force it... | 15:02 |
| gordonDrogon | it's not desperatly important. using ff to do quick video previews is fine for me for now. | 15:02 |
| gnarface | oh, one thing you can try | 15:03 |
| gnarface | i forgot | 15:03 |
| gordonDrogon | vlc has an option in the codes tools - it just has auto/vdpau/disable | 15:03 |
| gordonDrogon | seems to make no difference which I choose. | 15:03 |
| gnarface | hang on, intel-specific packages incoming | 15:03 |
| gnarface | try these: i965-va-driver, intel-media-va-driver, libvdpau-va-gl1 | 15:04 |
| gnarface | and also, double check you have these: https://paste.debian.net/1322668/ | 15:04 |
| gordonDrogon | oh, I just installed mpv - silky smooth. | 15:04 |
| gnarface | mpv is probably smart enough to use either | 15:05 |
| gordonDrogon | those are already installed. | 15:05 |
| gnarface | though, for what it's worth that libvdpau-va-gl1 is a wrapper from opengl to vaapi, so for old intel hardware you can set it to regular opengl accel and it'll translate it to vaapi, works decent | 15:06 |
| gnarface | (useful for mplayer, i suppose that's one thing mpv adds over mplayer though0 | 15:06 |
| gnarface | ) | 15:06 |
| gordonDrogon | and I have all the amd64 version of those packages in that paste. | 15:06 |
| gordonDrogon | maybe vlc's days are numbered... | 15:06 |
| gnarface | i think hardware that doesn't support both protocols days are numbered | 15:07 |
| gnarface | *these days | 15:07 |
| gnarface | these days' days are numbered? | 15:07 |
| gnarface | nevermind | 15:07 |
| gordonDrogon | :) | 15:07 |
| gnarface | there might be a way to build vlc with vaapi support | 15:08 |
| gordonDrogon | https://wiki.videolan.org/VLC_VAAPI/ | 15:13 |
| gordonDrogon | looks like it all ought to be there | 15:13 |
| gordonDrogon | and theres a load of 'failed' output messages when trying to open stuff | 15:15 |
| gordonDrogon | https://unicorn.drogon.net/vlc0.txt | 15:15 |
| gordonDrogon | but sometimes when you find another solution.... always odd to change though as vlc has served me well for decades... (or it seems that way) | 15:18 |
| gnarface | do you have these? i965-va-driver, intel-media-va-driver, libvdpau-va-gl1 | 15:19 |
| gnarface | there's still every possibility you're just missing a library | 15:19 |
| gnarface | or mabye there's just something weird about the debian build... | 15:20 |
| gnarface | you should be able to verify by the output of vdpauinfo and vainfo | 15:20 |
| gordonDrogon | yes, got those. | 15:21 |
| gordonDrogon | let me just check it again on my laptop - I'm sure it was working just fine there. | 15:21 |
| gordonDrogon | it's also a dell/intel. | 15:21 |
| gnarface | if you have a good cpu and it's a small video it might not be obvious by framerate all the time, but there should be an obvious difference in cpu load | 15:22 |
| gordonDrogon | yea, silky smooth with vlc on the laptop - I'm suspecting something left-over from the upgrade process I did some months back | 15:22 |
| gnarface | i don't actually mess with intel video a lot, so unfortunately i can't really test here | 15:23 |
| gnarface | just going off old info from helping other people a couple releases back... | 15:23 |
| gordonDrogon | thanks. | 15:23 |
| gordonDrogon | laptop has cpu topping at 75% but desktop is peaking 110% for vlc. guess it's not using hardware | 15:24 |
| gnarface | oh, hmm... i did have a intel laptop though and something else occurs to me... | 15:24 |
| gnarface | you're using xorg not wayland, right? | 15:24 |
| gordonDrogon | right | 15:25 |
| gnarface | i recall that the default xorg driver at some point changed from intel to modesetting (at intel's request) | 15:25 |
| gnarface | but i discovered that some video decoding profiles didn't work in modesetting | 15:25 |
| gnarface | so i had to switch it back to intel | 15:25 |
| gnarface | that might only affect certain encodings | 15:26 |
| gordonDrogon | I've not really looked 'under the hood' for a long time now. sort of given up as it was a bit too much to keep up with | 15:26 |
| gnarface | try like some h264 videos and see if they behave any better, for example | 15:26 |
| gnarface | look in the output of "vainfo" and try something that matches one of them | 15:26 |
| gnarface | you said it's MP4 video, but MP4 is the name of both a container format and a encoding format, and they're not necessarily always used in conjunction (rarely in fact, these days) | 15:27 |
| gnarface | so there's ambiguity there | 15:27 |
| gordonDrogon | the files do appear to be h264 - right off the GoPro H8 | 15:28 |
| gnarface | hmm | 15:28 |
| gordonDrogon | yea, I understand the container thingy though. | 15:28 |
| gnarface | usually h264 is what everything supports best these days, though with some hardware (my raspberry pi) it seems to be picky about pixel format as well | 15:28 |
| gnarface | cameras often use yuyv422, or something similar, but certain decoding hardware insists on it being yuv420p or it won't accelerate | 15:29 |
| gordonDrogon | (Ugh. heres another whinge - why do some applications change the CWD on startup!) vaguely related to this - openshot-qt I'm looking at you - I cd to dir fill of files, start you and you default to $HOME! Curse you. | 15:30 |
| gnarface | if the video isn't in yuv420p you could try re-encoding it as such with ffmpeg | 15:31 |
| gnarface | then see if it behaves better | 15:31 |
| gnarface | i think with that i'm out of ideas though | 15:31 |
| gordonDrogon | it's fine,. thanks, I have solutions. Lookis like openshot is just as broken as it ever was though. | 15:35 |
| gordonDrogon | but since I managed to lose the battery door to the GoPro the other day I may not be taking videos for a while. | 15:36 |
| gordonDrogon | stupid design. | 15:36 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!