Wow, my system got wrecked (exaggeration) during this latest stretch...
Pulseaudio was stretched to the limit and beyond and was forced to
restart. Anything that was producing audio had to be restarted to get
it back.
This time was much like the first time and went from timestamp
573100.060927 (lin
You can ignore the last set of files with a sample of 1.
I got a nice sample of like 150 about 6 hours ago.
The link I included in the previous reply contains the same filenames,
just updated.
The journal timestamps (to correspond with the trace times) go from
"[513438.430253] computername kernel:
OK, I finally got one... but there was only 1 journal log entry. The
previous time there were like maybe 10 (also very little), but the 2
times before that had enough for me to have to page through the log.
I actually messed up on a variable in my script so missed the actual
time, but the trace st
I'm only posting to say I'm still waiting...
The error came up while I slept, and when I copied that log and looked
at it (yes, it WAS huge, just as you said), the timestamps at the
head/tail were much later than the journal logged times.
So I made a little script to monitor the journal kernel entr
...But then again, maybe it wasn't the cable. It's acting up again.
On Tue, Jan 1, 2019 at 3:14 PM Nathan Royce wrote:
>
> Looks like this particular issue may have been due to a touchy/finicky
> connection.
>
> I removed my tuner from my hub and removed the hub from m
opped.
Just to be sure, I also rebooted and it's still fine. No xhci errors at all.
The only thing I've done recently (within the past few days) was play
with my scanner which is also on that hub and maybe brushed my tuner
cable or something.
On Tue, Jan 1, 2019 at 12:57 PM Nath
Kernel 4.19.13
00:14.0 USB controller: Intel Corporation 9 Series Chipset Family USB
xHCI Controller
Around 400 "unknown event type 37" messages logged in a 2 second span.
*
Jan 01 02:08:07 computername tvheadend[2370]: linuxdvb: Auvitek AU8522
QAM/8VSB Frontend #0 : ATSC-T #0 - poll TIMEOUT
