[mythtv-users] Trac rejected bug report as spam

Michael T. Dean mtdean at thirdcontact.com
Tue Aug 8 11:27:03 UTC 2017


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



More information about the mythtv-users mailing list