Mailing List Archive

Trac rejected bug report as spam
I was just trying to file a bug report on Trac, and I got back a
message saying that Trac had rejected it as being a high probability
of being spam. This is what I was trying to put in the bug report:

MythTV Version : v0.28.1-38-geef6a48
MythTV Branch : fixes/0.28
Network Protocol : 88
Library API : 0.28.20161120-1
QT Version : 5.5.1
Options compiled in:
linux profile use_hidesyms using_alsa using_oss using_pulse
using_pulseoutput using_backend using_bindings_perl
using_bindings_python using_bindings_php using_crystalhd using_dvb
using_firewire using_frontend using_hdhomerun using_vbox using_ceton
using_hdpvr using_ivtv using_joystick_menu using_libcec
using_libcrypto using_libdns_sd using_libfftw3 using_libxml2
using_lirc using_mheg using_opengl using_opengl_video
using_opengl_themepainter using_qtwebkit using_qtscript using_qtdbus
using_sdl using_taglib using_v4l2 using_x11 using_xrandr using_xv
using_profiletype using_bindings_perl using_bindings_python
using_bindings_php using_freetype2 using_mythtranscode using_opengl
using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass
using_libxml2

I had a recording failure for a recording using minisatip (IPTV) for
Midsomer Murders. The recording never started due to a problem in
minisatip. When I eventually noticed it, I manually stopped the
recording. Then, when I called the Dvr/GetUpcomingList?Count=1 API, I
was getting back a result saying that the Midsomer Murders recording
scheduled for 2017-08-08T00:45:00Z is the next recording to happen
(see GetUpcomingList.xml file). That start time was in the past, but
the end time for that failed recording (2017-08-08T02:25:00Z) was
still in the future. I tried restarting mythbackend, but that did not
change anything. I then waited until after that end time, and the API
call then correctly returned the next scheduled recording.

GetUpcomingList.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<ProgramList xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="1.0"
serializerVersion="1.1"><StartIndex>0</StartIndex><Count>1</Count><TotalAvailable>173</TotalAvailable><AsOf>2017-08-08T02:06:30Z</AsOf><Version>0.28.20161120-1</Version><ProtoVer>88</ProtoVer><Programs><Program><StartTime>2017-08-08T00:45:00Z</StartTime><EndTime>2017-08-08T02:25:00Z</EndTime><Title>Midsomer
Murders</Title><SubTitle>Death In The Slow
Lane</SubTitle><Category>Drama</Category><CatType>series</CatType><Repeat>false</Repeat><VideoProps>0</VideoProps><AudioProps>0</AudioProps><SubProps>0</SubProps><SeriesId>246304915</SeriesId><ProgramId/><Stars>0</Stars><LastModified>2017-08-08T02:01:46Z</LastModified><ProgramFlags>0</ProgramFlags><Airdate/><Description>New
DCI John Barnaby arrives and when a local DJ is crushed to death, he
soon discovers that murder and deception are never far
aw</Description><Inetref/><Season>0</Season><Episode>0</Episode><TotalEpisodes>0</TotalEpisodes><FileSize>0</FileSize><FileName/><HostName>mypvr</HostName><Channel><ChanId>10007</ChanId><ChanNum>4007</ChanNum><CallSign>UKTV</CallSign><IconURL/><ChannelName>UKTV</ChannelName><MplexId>0</MplexId><ServiceId>1003</ServiceId><ATSCMajorChan>0</ATSCMajorChan><ATSCMinorChan>0</ATSCMinorChan><Format>Default</Format><FrequencyId/><FineTune>0</FineTune><ChanFilters/><SourceId>6</SourceId><InputId>0</InputId><CommFree>false</CommFree><UseEIT>false</UseEIT><Visible>true</Visible><XMLTVID>uktv.sky.co.nz</XMLTVID><DefaultAuth/><Programs/></Channel><Recording><RecordedId>0</RecordedId><Status>Failed</Status><Priority>0</Priority><StartTs>2017-08-08T00:45:00Z</StartTs><EndTs>2017-08-08T02:28:00Z</EndTs><FileSize>0</FileSize><FileName/><HostName>mypvr</HostName><LastModified>2017-08-08T02:01:46Z</LastModified><RecordId>15043</RecordId><RecGroup>Default</RecGroup><PlayGroup>Default</PlayGroup><StorageG
roup>Default</StorageGroup><RecType>4</RecType><DupInType>15</DupInType><DupMethod>6</DupMethod><EncoderId>0</EncoderId><EncoderName/><Profile>Default</Profile></Recording><Artwork><ArtworkInfos/></Artwork><Cast><CastMembers/></Cast></Program></Programs></ProgramList>

Does anyone have any idea as to why Trac would think this is spam?
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Trac rejected bug report as spam [ In reply to ]
On 08/08/17 03:59, Stephen Worthington wrote:

> I had a recording failure for a recording using minisatip (IPTV) for
> Midsomer Murders. The recording never started due to a problem in
> minisatip. When I eventually noticed it, I manually stopped the
> recording. Then, when I called the Dvr/GetUpcomingList?Count=1 API, I
> was getting back a result saying that the Midsomer Murders recording
> scheduled for 2017-08-08T00:45:00Z is the next recording to happen
> (see GetUpcomingList.xml file). That start time was in the past, but
> the end time for that failed recording (2017-08-08T02:25:00Z) was
> still in the future. I tried restarting mythbackend, but that did not
> change anything. I then waited until after that end time, and the API
> call then correctly returned the next scheduled recording.

>
> Does anyone have any idea as to why Trac would think this is spam?

I see that it has now got in.

In the past I found that a failed recording could be restarted if it was
deleted from 'Previously recorded' - but now, on this box, that is only
showing me programmes from more than two years ago; I still don't know why.


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Trac rejected bug report as spam [ In reply to ]
On 08/07/2017 10:59 PM, Stephen Worthington wrote:
> I was just trying to file a bug report on Trac, and I got back a
> message saying that Trac had rejected it as being a high probability
> of being spam. This is what I was trying to put in the bug report:
>
> MythTV Version : v0.28.1-38-geef6a48
> MythTV Branch : fixes/0.28
> Network Protocol : 88
> Library API : 0.28.20161120-1
> QT Version : 5.5.1
> Options compiled in:
> linux profile use_hidesyms using_alsa using_oss using_pulse
> using_pulseoutput using_backend using_bindings_perl
> using_bindings_python using_bindings_php using_crystalhd using_dvb
> using_firewire using_frontend using_hdhomerun using_vbox using_ceton
> using_hdpvr using_ivtv using_joystick_menu using_libcec
> using_libcrypto using_libdns_sd using_libfftw3 using_libxml2
> using_lirc using_mheg using_opengl using_opengl_video
> using_opengl_themepainter using_qtwebkit using_qtscript using_qtdbus
> using_sdl using_taglib using_v4l2 using_x11 using_xrandr using_xv
> using_profiletype using_bindings_perl using_bindings_python
> using_bindings_php using_freetype2 using_mythtranscode using_opengl
> using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass
> using_libxml2
>
> I had a recording failure for a recording using minisatip (IPTV) for
> Midsomer Murders. The recording never started due to a problem in
> minisatip. When I eventually noticed it, I manually stopped the
> recording. Then, when I called the Dvr/GetUpcomingList?Count=1 API, I
> was getting back a result saying that the Midsomer Murders recording
> scheduled for 2017-08-08T00:45:00Z is the next recording to happen
> (see GetUpcomingList.xml file). That start time was in the past, but
> the end time for that failed recording (2017-08-08T02:25:00Z) was
> still in the future. I tried restarting mythbackend, but that did not
> change anything. I then waited until after that end time, and the API
> call then correctly returned the next scheduled recording.
>
> GetUpcomingList.xml file:
> <?xml version="1.0" encoding="UTF-8"?>
> <ProgramList xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> version="1.0"
> serializerVersion="1.1"><StartIndex>0</StartIndex><Count>1</Count><TotalAvailable>173</TotalAvailable><AsOf>2017-08-08T02:06:30Z</AsOf><Version>0.28.20161120-1</Version><ProtoVer>88</ProtoVer><Programs><Program><StartTime>2017-08-08T00:45:00Z</StartTime><EndTime>2017-08-08T02:25:00Z</EndTime><Title>Midsomer
> Murders</Title><SubTitle>Death In The Slow
> Lane</SubTitle><Category>Drama</Category><CatType>series</CatType><Repeat>false</Repeat><VideoProps>0</VideoProps><AudioProps>0</AudioProps><SubProps>0</SubProps><SeriesId>246304915</SeriesId><ProgramId/><Stars>0</Stars><LastModified>2017-08-08T02:01:46Z</LastModified><ProgramFlags>0</ProgramFlags><Airdate/><Description>New
> DCI John Barnaby arrives and when a local DJ is crushed to death, he
> soon discovers that murder and deception are never far
> aw</Description><Inetref/><Season>0</Season><Episode>0</Episode><TotalEpisodes>0</TotalEpisodes><FileSize>0</FileSize><FileName/><HostName>mypvr</HostName><Channel><ChanId>10007</ChanId><ChanNum>4007</ChanNum><CallSign>UKTV</CallSign><IconURL/><ChannelName>UKTV</ChannelName><MplexId>0</MplexId><ServiceId>1003</ServiceId><ATSCMajorChan>0</ATSCMajorChan><ATSCMinorChan>0</ATSCMinorChan><Format>Default</Format><FrequencyId/><FineTune>0</FineTune><ChanFilters/><SourceId>6</SourceId><InputId>0</InputId><CommFree>false</CommFree><UseEIT>false</UseEIT><Visible>true</Visible><XMLTVID>uktv.sky.co.nz</XMLTVID><DefaultAuth/><Programs/></Channel><Recording><RecordedId>0</RecordedId><Status>Failed</Status><Priority>0</Priority><StartTs>2017-08-08T00:45:00Z</StartTs><EndTs>2017-08-08T02:28:00Z</EndTs><FileSize>0</FileSize><FileName/><HostName>mypvr</HostName><LastModified>2017-08-08T02:01:46Z</LastModified><RecordId>15043</RecordId><RecGroup>Default</RecGroup><PlayGroup>Default</PlayGroup><StorageG
> roup>Default</StorageGroup><RecType>4</RecType><DupInType>15</DupInType><DupMethod>6</DupMethod><EncoderId>0</EncoderId><EncoderName/><Profile>Default</Profile></Recording><Artwork><ArtworkInfos/></Artwork><Cast><CastMembers/></Cast></Program></Programs></ProgramList>
>
> Does anyone have any idea as to why Trac would think this is spam?

FWIW, it's being seen as probable spam because of all the extra junk in
the description that's supposed to be attached as a file. In this
particular case, all the markup is probably what's making it look very
much like spam.

See: https://code.mythtv.org/trac/wiki/TicketHowTo

in particular:
-----
Once you've decided to ?create that ticket:
...
# Set the version to the version you use. If you see the bug with multiple
version, choose the newest. Add the output of mythfrontend --version or
mythbackend --version to the ticket. Make sure to read the line where it
says to attach this as a file
...
# Make sure you attach logs, patches, and backtraces after you create the
ticket.
-----

(where your GetUpcomingList output would be considered a "log").
Therefore, those two sections should be attached as a file rather than
included in the description.

Why do these things need to be attached as files, rather than included
in the description? Well, when you use a search, the description is
included in the default search fields (and, rightly should be). So that
means everything in your description will yield search hits. So, thanks
to including the --version output, which includes all the compile
options, your ticket now seems to involve:

alsa
oss
pulse
backend
perl
python
php
crystalhd
dvb
firewire
frontend
hdhomerun
vbox
ceton
hdpvr
ivtv
...

You get the idea. :)

And if you had actually submitted the ticket including the markup, it
would have also involved:

category
cattype
repeat
videoprops
audioprops
subprops
seriesid
stars
lastmodified
programflags
airdate
...

Note that you're not the only one to do this. In fact, over the years
it has been done so many times that the search function is Trac is
basically useless. This is part of the reason bugs are so hard to
find/handle.

It's not very intuitive for a user trying to create a bug report to
think of adding --version output as a file. We had actually discussed
making a custom field that's not included in the default search for
--version output, but there were already so many tickets with --version
that it didn't seem worthwhile, especially since there's also so many
log files and MythWeb debug/traces and other stuff included in
descriptions (and that would continue to be included in descriptions)
that handling just --version wouldn't solve the problem, anyway. So,
why doesn't someone go through and move all that information? Well, a
quick search for using_alsa has 604 results (probably none of which
actually involve using_alsa), and finding the logs and other such
information buried in descriptions is much harder, and the time it would
take to clean up all the bad tickets is a lot of time that could
actually be spent working on MythTV, so the motivation is low.

Mike

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Trac rejected bug report as spam [ In reply to ]
On Tue, Aug 08, 2017 at 07:27:03AM -0400, Michael T. Dean wrote:
>On 08/07/2017 10:59 PM, Stephen Worthington wrote:
>>I was just trying to file a bug report on Trac, and I got back a
>>message saying that Trac had rejected it as being a high probability
>>of being spam. This is what I was trying to put in the bug report:
>>

[cut]

>
>Note that you're not the only one to do this. In fact, over the years
>it has been done so many times that the search function is Trac is
>basically useless. This is part of the reason bugs are so hard to
>find/handle.

Has anyone thought of making a bug-reporting script? Something along the
lines of Debian's "reportbug", perl's "perlbug" etc. This could query
the user's system for version info, automatically include the last few
lines of the logs, report any differences between the user's config and
the stock config and so on. Think of it as an alternative to Trac's
"Submit Bug" form.

>
>It's not very intuitive for a user trying to create a bug report to
>think of adding --version output as a file. We had actually discussed
>making a custom field that's not included in the default search for
>--version output, but there were already so many tickets with
>--version that it didn't seem worthwhile, especially since there's
>also so many log files and MythWeb debug/traces and other stuff
>included in descriptions (and that would continue to be included in
>descriptions) that handling just --version wouldn't solve the problem,
>anyway. So, why doesn't someone go through and move all that
>information? Well, a quick search for using_alsa has 604 results
>(probably none of which actually involve using_alsa), and finding the
>logs and other such information buried in descriptions is much harder,
>and the time it would take to clean up all the bad tickets is a lot of
>time that could actually be spent working on MythTV, so the motivation
>is low.
>
>Mike
>
>_______________________________________________
>mythtv-users mailing list
>mythtv-users@mythtv.org
>http://lists.mythtv.org/mailman/listinfo/mythtv-users
>http://wiki.mythtv.org/Mailing_List_etiquette
>MythTV Forums: https://forum.mythtv.org

--
For more information, please reread.
Re: Trac rejected bug report as spam [ In reply to ]
On Tue, 8 Aug 2017 07:27:03 -0400, you wrote:

[snip]

My bad for not reading the bit about putting the --version output in a
file. But that does not seem to be what Trac is complaining about, as
it filed the ticket, but not my GetUpcomingList.xml file which I had
tried to add as an attachment. So I just tried adding it again, and
got the same error message:

Submission rejected as potential spam (SpamBayes determined spam
probability of 71.37%)

So it seems it is just complaining about that log file, and will not
allow it to be attached, despite it being a valid log.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Trac rejected bug report as spam [ In reply to ]
On Tue, Aug 8, 2017 at 2:57 PM, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:
> ....
> Submission rejected as potential spam (SpamBayes determined spam
> probability of 71.37%)

Well, you can likely feed your attachment
into SpamBayes and get additional hints
as to why you are spamming trac.....

I suspect that tuning the spam filter is
on the (countably) infinite TODO list
of one of the project admins as part of
the new trac that is (also) on that list.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Trac rejected bug report as spam [ In reply to ]
On 08/08/2017 10:57 AM, Stephen Worthington wrote:
> On Tue, 8 Aug 2017 07:27:03 -0400, you wrote:
>
> [snip]
>
> My bad for not reading the bit about putting the --version output in a
> file. But that does not seem to be what Trac is complaining about, as
> it filed the ticket, but not my GetUpcomingList.xml file which I had
> tried to add as an attachment. So I just tried adding it again, and
> got the same error message:
>
> Submission rejected as potential spam (SpamBayes determined spam
> probability of 71.37%)
>
> So it seems it is just complaining about that log file, and will not
> allow it to be attached, despite it being a valid log.
> _______________________________________________
>
I suggest putting the log in a pastebin as a workaround.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Trac rejected bug report as spam [ In reply to ]
On Tue, 8 Aug 2017 11:30:14 -0400, you wrote:

>
>
>On 08/08/2017 10:57 AM, Stephen Worthington wrote:
>> On Tue, 8 Aug 2017 07:27:03 -0400, you wrote:
>>
>> [snip]
>>
>> My bad for not reading the bit about putting the --version output in a
>> file. But that does not seem to be what Trac is complaining about, as
>> it filed the ticket, but not my GetUpcomingList.xml file which I had
>> tried to add as an attachment. So I just tried adding it again, and
>> got the same error message:
>>
>> Submission rejected as potential spam (SpamBayes determined spam
>> probability of 71.37%)
>>
>> So it seems it is just complaining about that log file, and will not
>> allow it to be attached, despite it being a valid log.
>> _______________________________________________
>>
>I suggest putting the log in a pastebin as a workaround.

Even easier than that, I have my own web server, so I have just put it
on there.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org