View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0020962 | MMW 5 | Main Panel | public | 2024-05-29 15:38 | 2024-07-31 20:57 |
| Reporter | lowlander | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | random |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.1 | ||||
| Target Version | 5.1 | Fixed in Version | 5.1 | ||
| Summary | 0020962: Inline edit doesn't accept keystrokes | ||||
| Description | On 3027 I experienced that inline edit didn't take keystrokes (ie. nothing changes when typing). Tried several fields, switching to different nodes also anew tab. Only restart resolved the issue. Only seen once. This also affects the Media Tree, Search, and the title of the Playlist panel. However Properties is unaffected. | ||||
| Additional Information | Ticket 7183 https://www.mediamonkey.com/forum/viewtopic.php?t=106265 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 3041 | ||||
|
|
Anyone can replicate this ? I haven't been successful to replicate so far. I wonder what is the trigger as based on the log the document.activeElement is correct and should accept keystrokes without issue.. |
|
|
MediaMonkeyEngine.exe using 7-10% CPU and 700+MB memory and increasing. Paused playback and CD Rip finished after discovery of failing to input, memory use continues to increase. So memory leak may be at play here. Once playback and CD Rip were finished, memory usage seemed to increase for a bit (after dropping at end of those tasks). Settling at ~5% CPU usage and 665MB memory usage. |
|
|
AV 46150000 also observed Edit Tags is not required for this. I also scoll wheel on mouse no longer working in Media Tree and Playing window, Filelisting still scrolls though. High CPU/Memory isn't consistent when this occurs. |
|
|
User at https://www.mediamonkey.com/forum/viewtopic.php?t=106265 reports like ticket 7183 that Send To > Playlists won't allow editing of Playlist name. |
|
|
@LowLander : Could you please re-test with 3029 whether the issue still happens? And if yes then test whether it happens also with artwork lookup disabled, i.e. try to temporarily disable all checkboxes in Options > Library > Metadata Lookup > Background metadata lookup |
|
|
Note that Artwork lookup was already disabled. Users report of Send To > Playlist > New Playlist saw this on 3029. I'm wondering if multiple sub-menus levels in the context menu is a trigger. However trying the same right after a restart (with or without Lyrics lookup enabled) did not trigger this issue. So it seems a longer sequence of events is required to get to this state. |
|
|
3029 - didn't accept keystrokes in inline edit in filelists, Auto-playlist editor (e.g. Title starts with ... couldn't type anything), title of Playlist editor (static), Preview panel / Allow edits, Search field... But Properties worked fine. It was once, after restart cannot replicate, but I have a log file when that happened, if you are interested. |
|
|
Actually, I could replicate it very often, even with cleared Portable folder. The video and log files in the 0020970 issue (https://www.ventismedia.com/mantis/view.php?id=20970#c75841). What is interesting, the Tab key works fine, but not Alt+F / Alt+V ... for the main menu. I am wondering if this issue is related to 0020514, since they similar symptoms (Search box inaccessible, mouse wheel not working). |
|
|
Just seen where inline edit of Original Date worked on a file, then editing next file it failed and MM stopped taking key entries in the main window. More users are saying they're experiencing this bug. |
|
|
I have no idea how to get to this state and nobody from the devs can replicate.. If you could catch some steps to reproduce, screencast and debug log it would be helpful to find a clue.. |
|
|
@Ludek, who are you asking? I posted video and log file. |
|
|
@Zvezdan: Good idea with the 0020514 -- the symtopms are similar and there the issue was that 'Hide editor' had 'MenuButton' class instead of 'ToolButton' so it was expanding something like "empty menu" resulting in the issue.. So maybe the fix would be deirectly in MenuButton class so that issue like this can't even happen.. |
|
|
It was a general issue in Menu class, when Menu was created with empty menuitems (undefined) and then attempted to show it resulted in the mentioned issue.. (main window not accepting keystrokes, but Tab key worked to switch Control) I have made a generall fix directly in the Menu constructor in build 3030 So please re-test in 3030 |
|
|
Actually found that it has been caused by fix of 0020960 => i.e. the crash no longer appears on menu open, but results in not accepting keystrokes in main window => Fixed in 3030 |
|
|
Verified 3039 |
|
|
And observed on 3038. I wonder if triggering Contextual search is a potential cause. However trying to reproduce this using Contextual Search, doesn't cause the issue. New log in same place. |
|
|
The log is useless and I strongly believe that this issue has been fixed in 3030 (confirmed by many).. Couldn't it be a test error or maybe your keyboard was temporarily disconnected / out of power? I guess it was a one time issue hardly to replicate again? Previously the issue was that the keystrokes were accepted by 'invisible' menu window, but I don't know how this could happen in case of Contextual Search? If you are unsucceful to replicate then just resolve -- as I haven't seen this being reported in 3030+ builds? |
|
|
No, keyboard was fine, this was on 3038. |
|
|
ok, by code revision I found a code tweak that could be related to this issue and fixed it.. So let's retest in 3041+ |
|
|
Closed on 3041, will re-open if this issue occurs again (it is rare that it does, doesn't have steps to reproduce). |
