Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/05/13/classpath.html

I’ve posted in
the past
about the Oracle vs. Google case. I’m for the moment sticking to my habit
of only commenting when there is a clear court decision. Having been
through litigation as the 30(b)(6) witness for Conservancy, I’m used to
court testimony and why it often doesn’t really matter in the long run. So
much gets said by both parties in a court case that it’s somewhat pointless
to begin analyzing each individual move, unless it’s for entertainment
purposes only. (It’s certainly as entertaining as most TV dramas, really,
but I hope folks who are watching step-by-step admit to themselves that
they’re just engaged in entertainment, not actual work. 🙂

I saw a lot go by today with various people as witnesses in the case.
About the only part that caught my attention was that Classpath was
mentioned over and over again. But that’s not for any real salient reason,
only because I remember so distinctly, sitting in a little restaurant in
New Orleans with RMS and Paul Fisher, talking about how we should name this
yet-to-be-launched GNU project “$CLASSPATH”. My idea was that
was a shell variable that would expand to /usr/lib/java, so,
in my estimation, it was a way to name the project “User Libraries
for Java” without having to say the words. (For those of you that
were still children in the 1990s, trademark aggression by Sun at the time
on the their word mark for “Java” was fierce, it was worse than
the whole problem the Unix trademark, which led in turn to the GNU
name.)

But today, as I saw people all of the Internet quoting judges, lawyers and
witnesses saying the word “Classpath” over and over again, it
felt a bit weird to think that, almost 20 years ago sitting in that
restaurant, I could have said something other than Classpath and the key
word in Court today might well have been whatever I’d said. Court cases
are, as I said, dramatic, and as such, it felt a little like having my own
name mentioned over and over again on the TV news or something. Indeed, I
felt today like I had some really pointless, one-time-use superpower that I
didn’t know I had at the time. I now further have this feeling of:
“darn, if I knew that was the one thing I did that
would catch on this much, I’d have tried to do or say something more
interesting”.

Naming new things, particularly those that have to replace other things
that are non-Free, is really difficult, and, at least speaking for myself,
I definitely can’t tell when I suggest a name whether it is any good or
not. I actually named another project, years later, that could
theoretically get mentioned in this
case, Replicant. At that time, I thought
Replicant was a much more creative name than Classpath. When I named
Classpath, I felt it was somewhat obvious corollary to the “GNU’S Not
Unix” line of thinking. I also recall distinctly that I really
thought the name lost all its cleverness when the $ and the all-caps was
dropped, but RMS and others insisted on that :).

Anyway, my final message today is to the court transcribers. I know from
chatting with the court transcribers during my depositions in Conservancy’s
GPL enforcement cases that technical terminology is really a pain. I hope
that the term I coined that got bandied about so much in today’s testimony
was not annoying to you all. Really, no one thinks about the transcribers
in all this. If we’re going to have lawsuits about this stuff, we should
name stuff with the forethought of making their lives easier when the
litigation begins. 🙂

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/05/13/classpath.html

I’ve posted in
the past
about the Oracle vs. Google case. I’m for the moment sticking to my habit
of only commenting when there is a clear court decision. Having been
through litigation as the 30(b)(6) witness for Conservancy, I’m used to
court testimony and why it often doesn’t really matter in the long run. So
much gets said by both parties in a court case that it’s somewhat pointless
to begin analyzing each individual move, unless it’s for entertainment
purposes only. (It’s certainly as entertaining as most TV dramas, really,
but I hope folks who are watching step-by-step admit to themselves that
they’re just engaged in entertainment, not actual work. 🙂

I saw a lot go by today with various people as witnesses in the case.
About the only part that caught my attention was that Classpath was
mentioned over and over again. But that’s not for any real salient reason,
only because I remember so distinctly, sitting in a little restaurant in
New Orleans with RMS and Paul Fisher, talking about how we should name this
yet-to-be-launched GNU project “$CLASSPATH”. My idea was that
was a shell variable that would expand to /usr/lib/java, so,
in my estimation, it was a way to name the project “User Libraries
for Java” without having to say the words. (For those of you that
were still children in the 1990s, trademark aggression by Sun at the time
on the their word mark for “Java” was fierce, it was worse than
the whole problem the Unix trademark, which led in turn to the GNU
name.)

But today, as I saw people all of the Internet quoting judges, lawyers and
witnesses saying the word “Classpath” over and over again, it
felt a bit weird to think that, almost 20 years ago sitting in that
restaurant, I could have said something other than Classpath and the key
word in Court today might well have been whatever I’d said. Court cases
are, as I said, dramatic, and as such, it felt a little like having my own
name mentioned over and over again on the TV news or something. Indeed, I
felt today like I had some really pointless, one-time-use superpower that I
didn’t know I had at the time. I now further have this feeling of:
“darn, if I knew that was the one thing I did that
would catch on this much, I’d have tried to do or say something more
interesting”.

Naming new things, particularly those that have to replace other things
that are non-Free, is really difficult, and, at least speaking for myself,
I definitely can’t tell when I suggest a name whether it is any good or
not. I actually named another project, years later, that could
theoretically get mentioned in this
case, Replicant. At that time, I thought
Replicant was a much more creative name than Classpath. When I named
Classpath, I felt it was somewhat obvious corollary to the “GNU’S Not
Unix” line of thinking. I also recall distinctly that I really
thought the name lost all its cleverness when the $ and the all-caps was
dropped, but RMS and others insisted on that :).

Anyway, my final message today is to the court transcribers. I know from
chatting with the court transcribers during my depositions in Conservancy’s
GPL enforcement cases that technical terminology is really a pain. I hope
that the term I coined that got bandied about so much in today’s testimony
was not annoying to you all. Really, no one thinks about the transcribers
in all this. If we’re going to have lawsuits about this stuff, we should
name stuff with the forethought of making their lives easier when the
litigation begins. 🙂

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/05/13/classpath.html

I’ve posted in
the past
about the Oracle vs. Google case. I’m for the moment sticking to my habit
of only commenting when there is a clear court decision. Having been
through litigation as the 30(b)(6) witness for Conservancy, I’m used to
court testimony and why it often doesn’t really matter in the long run. So
much gets said by both parties in a court case that it’s somewhat pointless
to begin analyzing each individual move, unless it’s for entertainment
purposes only. (It’s certainly as entertaining as most TV dramas, really,
but I hope folks who are watching step-by-step admit to themselves that
they’re just engaged in entertainment, not actual work. 🙂

I saw a lot go by today with various people as witnesses in the case.
About the only part that caught my attention was that Classpath was
mentioned over and over again. But that’s not for any real salient reason,
only because I remember so distinctly, sitting in a little restaurant in
New Orleans with RMS and Paul Fisher, talking about how we should name this
yet-to-be-launched GNU project “$CLASSPATH”. My idea was that
was a shell variable that would expand to /usr/lib/java, so,
in my estimation, it was a way to name the project “User Libraries
for Java” without having to say the words. (For those of you that
were still children in the 1990s, trademark aggression by Sun at the time
on the their word mark for “Java” was fierce, it was worse than
the whole problem the Unix trademark, which led in turn to the GNU
name.)

But today, as I saw people all of the Internet quoting judges, lawyers and
witnesses saying the word “Classpath” over and over again, it
felt a bit weird to think that, almost 20 years ago sitting in that
restaurant, I could have said something other than Classpath and the key
word in Court today might well have been whatever I’d said. Court cases
are, as I said, dramatic, and as such, it felt a little like having my own
name mentioned over and over again on the TV news or something. Indeed, I
felt today like I had some really pointless, one-time-use superpower that I
didn’t know I had at the time. I now further have this feeling of:
“darn, if I knew that was the one thing I did that
would catch on this much, I’d have tried to do or say something more
interesting”.

Naming new things, particularly those that have to replace other things
that are non-Free, is really difficult, and, at least speaking for myself,
I definitely can’t tell when I suggest a name whether it is any good or
not. I actually named another project, years later, that could
theoretically get mentioned in this
case, Replicant. At that time, I thought
Replicant was a much more creative name than Classpath. When I named
Classpath, I felt it was somewhat obvious corollary to the “GNU’S Not
Unix” line of thinking. I also recall distinctly that I really
thought the name lost all its cleverness when the $ and the all-caps was
dropped, but RMS and others insisted on that :).

Anyway, my final message today is to the court transcribers. I know from
chatting with the court transcribers during my depositions in Conservancy’s
GPL enforcement cases that technical terminology is really a pain. I hope
that the term I coined that got bandied about so much in today’s testimony
was not annoying to you all. Really, no one thinks about the transcribers
in all this. If we’re going to have lawsuits about this stuff, we should
name stuff with the forethought of making their lives easier when the
litigation begins. 🙂

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/05/13/classpath.html

I’ve posted in
the past
about the Oracle vs. Google case. I’m for the moment sticking to my habit
of only commenting when there is a clear court decision. Having been
through litigation as the 30(b)(6) witness for Conservancy, I’m used to
court testimony and why it often doesn’t really matter in the long run. So
much gets said by both parties in a court case that it’s somewhat pointless
to begin analyzing each individual move, unless it’s for entertainment
purposes only. (It’s certainly as entertaining as most TV dramas, really,
but I hope folks who are watching step-by-step admit to themselves that
they’re just engaged in entertainment, not actual work. 🙂

I saw a lot go by today with various people as witnesses in the case.
About the only part that caught my attention was that Classpath was
mentioned over and over again. But that’s not for any real salient reason,
only because I remember so distinctly, sitting in a little restaurant in
New Orleans with RMS and Paul Fisher, talking about how we should name this
yet-to-be-launched GNU project “$CLASSPATH”. My idea was that
was a shell variable that would expand to /usr/lib/java, so,
in my estimation, it was a way to name the project “User Libraries
for Java” without having to say the words. (For those of you that
were still children in the 1990s, trademark aggression by Sun at the time
on the their word mark for “Java” was fierce, it was worse than
the whole problem the Unix trademark, which led in turn to the GNU
name.)

But today, as I saw people all of the Internet quoting judges, lawyers and
witnesses saying the word “Classpath” over and over again, it
felt a bit weird to think that, almost 20 years ago sitting in that
restaurant, I could have said something other than Classpath and the key
word in Court today might well have been whatever I’d said. Court cases
are, as I said, dramatic, and as such, it felt a little like having my own
name mentioned over and over again on the TV news or something. Indeed, I
felt today like I had some really pointless, one-time-use superpower that I
didn’t know I had at the time. I now further have this feeling of:
“darn, if I knew that was the one thing I did that
would catch on this much, I’d have tried to do or say something more
interesting”.

Naming new things, particularly those that have to replace other things
that are non-Free, is really difficult, and, at least speaking for myself,
I definitely can’t tell when I suggest a name whether it is any good or
not. I actually named another project, years later, that could
theoretically get mentioned in this
case, Replicant. At that time, I thought
Replicant was a much more creative name than Classpath. When I named
Classpath, I felt it was somewhat obvious corollary to the “GNU’S Not
Unix” line of thinking. I also recall distinctly that I really
thought the name lost all its cleverness when the $ and the all-caps was
dropped, but RMS and others insisted on that :).

Anyway, my final message today is to the court transcribers. I know from
chatting with the court transcribers during my depositions in Conservancy’s
GPL enforcement cases that technical terminology is really a pain. I hope
that the term I coined that got bandied about so much in today’s testimony
was not annoying to you all. Really, no one thinks about the transcribers
in all this. If we’re going to have lawsuits about this stuff, we should
name stuff with the forethought of making their lives easier when the
litigation begins. 🙂

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/05/13/classpath.html

I’ve posted in
the past
about the Oracle vs. Google case. I’m for the moment sticking to my habit
of only commenting when there is a clear court decision. Having been
through litigation as the 30(b)(6) witness for Conservancy, I’m used to
court testimony and why it often doesn’t really matter in the long run. So
much gets said by both parties in a court case that it’s somewhat pointless
to begin analyzing each individual move, unless it’s for entertainment
purposes only. (It’s certainly as entertaining as most TV dramas, really,
but I hope folks who are watching step-by-step admit to themselves that
they’re just engaged in entertainment, not actual work. 🙂

I saw a lot go by today with various people as witnesses in the case.
About the only part that caught my attention was that Classpath was
mentioned over and over again. But that’s not for any real salient reason,
only because I remember so distinctly, sitting in a little restaurant in
New Orleans with RMS and Paul Fisher, talking about how we should name this
yet-to-be-launched GNU project “$CLASSPATH”. My idea was that
was a shell variable that would expand to /usr/lib/java, so,
in my estimation, it was a way to name the project “User Libraries
for Java” without having to say the words. (For those of you that
were still children in the 1990s, trademark aggression by Sun at the time
on the their word mark for “Java” was fierce, it was worse than
the whole problem the Unix trademark, which led in turn to the GNU
name.)

But today, as I saw people all of the Internet quoting judges, lawyers and
witnesses saying the word “Classpath” over and over again, it
felt a bit weird to think that, almost 20 years ago sitting in that
restaurant, I could have said something other than Classpath and the key
word in Court today might well have been whatever I’d said. Court cases
are, as I said, dramatic, and as such, it felt a little like having my own
name mentioned over and over again on the TV news or something. Indeed, I
felt today like I had some really pointless, one-time-use superpower that I
didn’t know I had at the time. I now further have this feeling of:
“darn, if I knew that was the one thing I did that
would catch on this much, I’d have tried to do or say something more
interesting”.

Naming new things, particularly those that have to replace other things
that are non-Free, is really difficult, and, at least speaking for myself,
I definitely can’t tell when I suggest a name whether it is any good or
not. I actually named another project, years later, that could
theoretically get mentioned in this
case, Replicant. At that time, I thought
Replicant was a much more creative name than Classpath. When I named
Classpath, I felt it was somewhat obvious corollary to the “GNU’S Not
Unix” line of thinking. I also recall distinctly that I really
thought the name lost all its cleverness when the $ and the all-caps was
dropped, but RMS and others insisted on that :).

Anyway, my final message today is to the court transcribers. I know from
chatting with the court transcribers during my depositions in Conservancy’s
GPL enforcement cases that technical terminology is really a pain. I hope
that the term I coined that got bandied about so much in today’s testimony
was not annoying to you all. Really, no one thinks about the transcribers
in all this. If we’re going to have lawsuits about this stuff, we should
name stuff with the forethought of making their lives easier when the
litigation begins. 🙂

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/05/13/classpath.html

I’ve posted in
the past
about the Oracle vs. Google case. I’m for the moment sticking to my habit
of only commenting when there is a clear court decision. Having been
through litigation as the 30(b)(6) witness for Conservancy, I’m used to
court testimony and why it often doesn’t really matter in the long run. So
much gets said by both parties in a court case that it’s somewhat pointless
to begin analyzing each individual move, unless it’s for entertainment
purposes only. (It’s certainly as entertaining as most TV dramas, really,
but I hope folks who are watching step-by-step admit to themselves that
they’re just engaged in entertainment, not actual work. 🙂

I saw a lot go by today with various people as witnesses in the case.
About the only part that caught my attention was that Classpath was
mentioned over and over again. But that’s not for any real salient reason,
only because I remember so distinctly, sitting in a little restaurant in
New Orleans with RMS and Paul Fisher, talking about how we should name this
yet-to-be-launched GNU project “$CLASSPATH”. My idea was that
was a shell variable that would expand to /usr/lib/java, so,
in my estimation, it was a way to name the project “User Libraries
for Java” without having to say the words. (For those of you that
were still children in the 1990s, trademark aggression by Sun at the time
on the their word mark for “Java” was fierce, it was worse than
the whole problem the Unix trademark, which led in turn to the GNU
name.)

But today, as I saw people all of the Internet quoting judges, lawyers and
witnesses saying the word “Classpath” over and over again, it
felt a bit weird to think that, almost 20 years ago sitting in that
restaurant, I could have said something other than Classpath and the key
word in Court today might well have been whatever I’d said. Court cases
are, as I said, dramatic, and as such, it felt a little like having my own
name mentioned over and over again on the TV news or something. Indeed, I
felt today like I had some really pointless, one-time-use superpower that I
didn’t know I had at the time. I now further have this feeling of:
“darn, if I knew that was the one thing I did that
would catch on this much, I’d have tried to do or say something more
interesting”.

Naming new things, particularly those that have to replace other things
that are non-Free, is really difficult, and, at least speaking for myself,
I definitely can’t tell when I suggest a name whether it is any good or
not. I actually named another project, years later, that could
theoretically get mentioned in this
case, Replicant. At that time, I thought
Replicant was a much more creative name than Classpath. When I named
Classpath, I felt it was somewhat obvious corollary to the “GNU’S Not
Unix” line of thinking. I also recall distinctly that I really
thought the name lost all its cleverness when the $ and the all-caps was
dropped, but RMS and others insisted on that :).

Anyway, my final message today is to the court transcribers. I know from
chatting with the court transcribers during my depositions in Conservancy’s
GPL enforcement cases that technical terminology is really a pain. I hope
that the term I coined that got bandied about so much in today’s testimony
was not annoying to you all. Really, no one thinks about the transcribers
in all this. If we’re going to have lawsuits about this stuff, we should
name stuff with the forethought of making their lives easier when the
litigation begins. 🙂

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/03/13/mythweb-database.html

I’m finally configuring Kodi properly to watch over-the-air channels using
this this
USB ATSC / DVB-T tuner card from Thinkpenguin. I hate taking time
away, even on the weekends, from the urgent Conservancy matters but I’ve
been doing by-hand recordings using VLC for my wife when she’s at work,
and I just need to present a good solution to my home to showcase software
freedom here.

So, I installed Debian testing to get a newr Kodi, I did
discover this
bug after it had already been closed but had to
pull util-linux out of unstable for the moment since it hadn’t
moved to testing.

Kodi works fine after installing it via apt, and since VDR is packaged for
Debian, I tried getting VDR working instead of MythTV at first. I almost
had it working but then I got this error:

VNSI-Error: cxSocket::read: read() error at 0/4

when trying to use kodi-pvr-vdr-vnsi (1.11.15-1) with vdr-plugin-vnsiserver
(1:1.3.1) combined with vdr (2.2.0-5) and kodi (16.0+dfsg1-1). I tried
briefly using the upstream plugins for both VDR and Kodi just to be sure
I’d produce the same error, and got the same so I started by reporting this
on the Kodi
VDR backend forum. If I don’t get a response there in a few weeks,
I’ll file it as a bug against kodi-pvr-vdr-vnsi instead.

For now, I gave up on VDR (which I rather liked, very old-school
Unix-server module was to build a PVR), and tried MythTV instead since it’s
also GPL’d. Since there weren’t Debian packages,
I followed
this building from source tutorial on MythTV’s website.

I didn’t think I’d actually
need to
install MythWeb at first, because I am using Kodi primarily and am only
using MythTV backend to handle the tuner card. It was pretty odd that you
can only configure MythTV via a QT program
called mythtv-setup, but ok, I did that, and it was
relatiavely straight forward. Once I did, playback was working reasonable
using Kodi’s MythTV plugin. (BTW, if you end up doing this, it’s fine to
test Kodi as its own in a window with a desktop environment running, but I
had playback speed issues in that usage, but they went away fully when I
switched to a simple .xinitrc that just
called kodi-standalone.

The only problem left was that I noticed that I was not
getting Event Information Table
(EIT) data from the card to add to
the Electronic
Program Guide (EPG). Then I discovered that
one must
install MythWeb for the EIT data to make it through via the plugin for EPG
in Kodi. Seems weird to me, but ok, I went to install MythWeb.

Oddly, this is where I had the most trouble, constantly receiving this
error message:

PHP Fatal error: Call to a member function query_col() on null in /path/to/mythweb/modules/backend_log/init.php on line 15

The top net.search hit is likely to
be this bug ticket
which
out points out
that this is a horrible form of an error message to tell you the equivalent
of “something is strange about the database configuration, but I’m
not sure what”.

Indeed, I tried a litany of items which i found through lots of
net.searching. Unfortunately I got a bit frantic, so I’m not sure which
one solved my problem (I think it was actually quite obviously multiple
ones :). I’m going to list them all here, in one place, so that future
searchers for this problem will find all of them together:

• Make sure the PHP load_path is coming through properly and
  includes the MythTV backend directory, ala:

  setenv include_path “/path/to/mythtv/share/mythtv/bindings/php/”

• Make sure the mythtv user has a password set properly and is
  authorized in the database users table to have access from localhost,
  ::1, and 127.*, as it’s sometimes unclear which way Apache might
  connect.
• In Debian testing, make sure PHP 7 is definitely not in use by MythWeb
  (I am guessing it is incompatible), and make sure the right PHP5 MySql
  modules are installed.
  The MythWeb
  installation instructions do say:

  apache2-mpm-prefork php5 php5-mysql libhttp-date-perl

  And at one point, I somehow got php5-mysql installed and
  libapache2-mod-php5 without having php5 installed, which I think may have
  caused a problem.

• Also, read

  this
  thread from the MythTV mailing list as it is the most comprehensive
  in discussing this error.

I did have
to update the
channel lineup with mythfilldatabase --dd-grab-all